salesforce-metadata-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.8.7
Disambiguation3/5
Many tools have clearly distinct purposes, but several overlapping pairs exist (e.g., sf_create_custom_notification_type vs sf_create_notification_type, sf_create_field_update vs sf_create_workflow_field_update, sf_create_role vs sf_create_user_role_hierarchy). These duplicates create ambiguity and require careful reading of descriptions to select the correct tool.
Naming Consistency4/5
The overwhelming majority use a consistent sf_verb_noun pattern (e.g., sf_create_custom_object, sf_get_apex_class, sf_activate_flow). Minor deviations like sf_devops_create_work_item versus sf_checkout_devops_work_item, and verbs like 'scan' or 'guide' that don't follow the create/get/update/delete pattern, are occasional but not chaotic.
Tool Count1/5
With 221 tools, this is an extreme over-scoping. The rubric clearly marks 50+ tools as excessive, and this far exceeds that threshold. The server covers nearly every Salesforce feature, making it unwieldy and impractical for an agent to select from effectively.
Completeness3/5
The tool set covers a broad range of Salesforce operations, but many metadata types lack full CRUD lifecycle support (e.g., custom objects only have create, no update/delete; flows have create/activate/deactivate but no get/delete; Apex classes have create/get but no update/delete). The presence of generic sf_deploy_metadata and sf_retrieve_metadata mitigates some gaps, but the per-resource tools are incomplete.
Average 4.1/5 across 221 of 221 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 45 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source and rename option but doesn't explain behavior on existing components, overwrite semantics, or the effect of the activate parameter. The inaccurate parameter names further muddy expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and informative, but the subsequent parameter list is redundant (since the schema already describes parameters) and inaccurate. It does not earn its place and detracts from the overall structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a write operation with no output schema, the description should explain import behavior, prerequisites, and consequences. It only mentions the source and rename, omitting details about whether the import creates or updates, what happens if the component exists, and the activate parameter. The missing behavior and inaccurate parameter list leave significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all parameters (100% coverage), so the description should add minimal extra value. However, it introduces mismatched names (exportedJson, newComponentName) instead of the actual parameter names (jsonDefinition, newName), and lists component types not present in the schema enum. This actively misleads rather than clarifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports an OmniStudio component from previously exported JSON, which is a specific verb+resource and distinguishes it from create tools. The mention of the source format and optional rename adds clarity, though the subsequent parameter list introduces some confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after exporting with sf_export_omnistudio_component, giving a clear context. However, it does not explicitly state when not to use this tool or mention alternatives, leaving the guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false, so the write nature is understood. The description adds the behavioral context of managers viewing/adjusting forecasts, but does not disclose side effects like overwriting existing assignments or permission requirements. Not contradictory, but minimal added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is concise and useful, but the subsequent parameter list is redundant with schema descriptions and contains inaccurate parameter names, wasting space and causing confusion. The structure is front-loaded but undermined by incorrect details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not align with the actual schema, omitting the real parameters and behavior around existing entries. It also lacks details on what happens if the hierarchy relationship already exists or how the forecastingType relates to the schema options. Incomplete for a configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description introduces managerUsername and reporteeUsername parameters that do not exist in the schema, while omitting actual schema parameters (isActive, roleName, displayCurrency). This is actively misleading and could cause agents to invoke the tool incorrectly despite the schema having 100% description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Configures a Collaborative Forecasting hierarchy entry') and resource, and distinguishes this tool from siblings like role hierarchy tools by focusing on forecast managers and reportees. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for setting up forecast manager relationships but does not explicitly state when to use it vs. alternatives or any exclusions. It provides context but lacks direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds useful context that the tool reads the current configuration before applying changes, which helps anticipate its behavior. However, it does not explain the mechanics of the update (e.g., merge vs. replace) or acknowledge the component-related parameters, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the primary purpose. It is appropriately concise and includes a helpful callout to an alternative tool. However, the first sentence's phrasing ('title or description') is slightly imprecise given the actual parameters, which costs it a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and five parameters, the description should clarify what the tool does with each parameter and what the update entails. It does not mention runningUser or the component arrays, and its statement about structural changes contradicts the schema. This leaves a significant gap in understanding the tool's full capabilities and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 each parameter. The description adds little value and actually misleads by mentioning 'description' (no such parameter exists) and implying structural changes are not supported, while the schema clearly includes componentsToAdd and componentsToRemove. This actively harms parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Updates an existing Dashboard's title or description') and distinguishes it from sf_create_dashboard, but it is misleading because the schema includes parameters for adding/removing components (componentsToAdd, componentsToRemove), which the description explicitly says to handle via sf_create_dashboard instead. This internal contradiction diminishes clarity about the tool's actual scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-to-use guidance ('The dashboard must already exist') and when-not-to-use guidance with a named alternative ('For structural changes... use sf_create_dashboard to create a new version'). This is clear, actionable, and distinguishes it from a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint false and destructiveHint false, so the tool is known to be mutable but not purely destructive. The description adds useful behavioral context by stating it polls until the job completes and returns success/failure counts, but it does not disclose failure handling or authorization requirements. This is acceptable but not exceptional given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences and front-loaded with the core purpose, but the CSV instruction is both inaccurate and unnecessary, adding noise. The structure flows logically from purpose to operations to special handling, but the extraneous sentence and lack of error handling details make it only average.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain return values; it only says 'returns success/failure counts' without detailing the structure. It covers operation types, large datasets, external ID, and polling, but misses critical context like requiring record IDs for delete operations and how to interpret failure details. Given the tool's complexity and the presence of specialized siblings, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds an explanation for externalIdField, but it also states 'Provide CSV data with a header row,' which directly contradicts the schema's expectation of an array of record objects. This misleading instruction undermines parameter clarity, reducing the score below baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool bulk imports records using Salesforce Bulk API 2.0 and supports insert, upsert, update, and delete operations, distinguishing it from specialized bulk tools like sf_bulk_insert_records. However, the mention of 'Provide CSV data with a header row' conflicts with the JSON array schema, slightly muddying the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for large datasets and notes that it polls until completion, but it does not explicitly mention when to use this tool over specialized siblings (e.g., sf_bulk_insert_records) or exclude scenarios. The guidance is contextual but lacks clear when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains routing behavior ('route to a queue' or 'route to an Einstein Bot first') and conditional parameter requirements, which adds value beyond the annotations. However, it does not disclose behavior related to the idempotentHint annotation, such as whether creating an existing channel overwrites or fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with line breaks per parameter and no redundant prose. Every sentence adds information, though the incorrect enum lists waste some space and reduce reliability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 2 enums, no output schema), the description covers many important aspects: channel types, phone format, routing logic, and a post-create step. However, it omits the 'None' routingType option and fails to clarify idempotent behavior or expected outcome, leaving gaps for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful parameter context: E.164 format for phoneNumber, pageId purpose, and conditional requirements for queueName/botName. Yet it directly conflicts with the schema enum: it lists 'AppleBusinessChat', 'EinsteinBotChannel', and 'WebChat' (not in schema), omits 'Voice' and 'EmbeddedMessaging', and says routingType is 'Queue or Bot' while the schema includes 'None'. This is misleading and likely to cause invocation errors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a Messaging Channel for Salesforce digital engagement' and enumerates the channel types it covers, which distinguishes it from sibling tools like sf_create_service_channel. However, the channelType list in the description diverges from the schema enum, creating slight ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a contextual use case ('for Salesforce digital engagement') and a follow-up step ('After creating, configure the channel with sf_create_embedded_service'), implying when to use it. It does not explicitly state alternatives or exclusions, leaving the when-not-to-use guidance absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'creates a work item' and describes the entity, but does not disclose behavioral traits beyond annotations. It omits details like return value, side effects, prerequisites (e.g., existing DevOps project), or error conditions. Annotations (readOnlyHint=false, idempotentHint=false) already indicate mutation, but the description adds no additional behavioral context beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the action. It opens with a clear purpose and follows with a brief explanation of work items. However, the parameter list duplicates the schema descriptions, which is unnecessary and slightly wasteful, though not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters (1 required), no output schema, and basic annotations. The description explains what a work item is and its lifecycle, but does not mention what is returned on creation, where to get pipelineStageId/assignedToId, or any prerequisites. It's minimally viable but has clear gaps for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully explained in the input schema. The description repeats the parameter names and short descriptions, adding no new semantic meaning such as format, constraints, relationships, or how to obtain values like pipelineStageId. Thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Creates a work item in Salesforce DevOps Center.' This is a specific verb (creates) plus a specific resource (work item), distinguishing it from sibling tools like sf_checkout_devops_work_item or sf_list_devops_work_items. It also adds context about what work items are, reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the domain context (work items move through pipeline stages) but does not explicitly state when to use this tool versus alternatives like sf_create_devops_pull_request. No exclusions or alternative recommendations are provided, so an agent must infer usage from the name and domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the fact that this is a mutation is established. The description adds conceptual context about pipeline progression but does not disclose any further behavioral traits such as side effects, required stage conditions, reversibility, or return behavior. Given that annotations cover the basic safety profile, the description adds some but limited value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action. The second sentence provides useful context about the pipeline. However, the parameter line is redundant since it duplicates the schema description, which prevents a perfect conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with one parameter and no output schema, the description covers the basic purpose. However, it does not explain what happens after promotion, what the result indicates, or how it differs from the similarly named sibling 'sf_promote_devops_work_item'. This leaves some ambiguity for an agent deciding between tools or interpreting the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter 'workItemId' with description 'DevOps Center work item ID'. The description repeats this as 'workItemId: the DevOps Center work item record ID', but adds no new meaning. With 100% schema coverage, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Promotes a DevOps Center work item to the next pipeline stage.' This is a specific verb+resource combination. However, it does not distinguish itself from the sibling tool 'sf_promote_devops_work_item', which appears to have the same purpose, preventing a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides contextual information about the pipeline progression ('represents the progression of changes from development environments toward production'), which implies when the tool should be used. However, it does not explicitly state when to use this tool vs. alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is a write operation (readOnlyHint=false) and not destructive. The description adds useful behavioral context: 'Site starts in UnderConstruction status by default' and explains how urlPathPrefix affects the URL. This goes beyond the annotations but does not cover potential side effects like duplicate names 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences and no redundant statements. It front-loads the core action, then efficiently covers templates, URL behavior, and default status. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 7 parameters and 100% schema coverage, the description adds enough context for the main decision points. It covers template options, URL prefix semantics, and default status. There is no output schema, so return values need not be explained. It does not mention error scenarios or prerequisites, but these are not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a baseline of 3 applies. The description enhances parameter understanding by explaining template use cases (e.g., 'CustomerService (B2C self-service)') and providing a concrete urlPathPrefix example ('customers' → org.force.com/customers). This adds value beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Creates an Experience Cloud site (formerly Community) using a specified template.' It is specific about the resource and includes useful details like template types. However, it does not explicitly distinguish itself from sibling tools such as sf_create_experience_page, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no reference to sf_create_experience_page or any other tool, and no exclusions or prerequisites are mentioned. The template list implies certain use cases, but this is more about parameter options than usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds that reports are created in a specified folder or personal folder by default, and lists supported formats, which is useful context. However, it does not disclose potential side effects like overwriting existing reports, permission requirements, or whether retries could create duplicates. It adds some value but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences that front-load the core action and include supported formats, required inputs, and folder default. No filler or redundant phrasing; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 4 required, no output schema), the description covers the main selection criteria (formats, required fields, filters) and folder default, but it does not explain return values, error handling, or any prerequisites. Without an output schema, the description should mention what the tool returns (e.g., report ID or URL), which is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 a bit of color by giving examples for reportType ('Accounts, Opportunities') and mentioning the default folder for folderName, but these are largely redundant with the schema descriptions. It provides marginal added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Salesforce Report using the Report metadata type, which is a specific verb+resource. It distinguishes from similar creation tools like sf_create_report_type by focusing on the Report itself, though it doesn't explicitly contrast with siblings. The phrase 'Specify the report type' could be mildly confusing given the sibling tool name, but overall purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing what the tool does and mentions the default folder behavior, but it does not explicitly state when to use this tool versus alternatives (e.g., sf_create_report_type, sf_create_dashboard). No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful domain context about how roles control record visibility, which goes beyond the annotations. Yet it does not disclose potential side effects (e.g., impact on existing users or permission requirements) or explain the meaning of access level parameters, leaving the behavioral picture incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an initial concise summary followed by a parameter list. It is slightly longer than the minimal two-sentence ideal but every sentence adds value, particularly the roleName/label/parentRoleName clarifications. No redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and 2 required, the description covers only 4 of them, but the schema provides full descriptions for all. The tool has no output schema, so return value expectations are not addressed. The description explains the core purpose but omits important context about how access level parameters affect the hierarchy and what happens if parentRoleName does not exist, leaving the description adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so baseline is 3. The description adds meaningful semantics for key parameters: roleName is 'API name (no spaces, used as DeveloperName)', label is 'display name shown in Setup', and parentRoleName can be 'omit for a top-level role'. This clarifies usage beyond the schema's terse descriptions, though access-level parameters receive no additional explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates a new UserRole') and the resource ('in the Salesforce Role Hierarchy'), which is specific and unambiguous. However, it does not explicitly distinguish this tool from sibling tools like 'sf_create_role_hierarchy' or 'sf_create_role', so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when this tool is relevant by describing role hierarchy and OWD visibility, and it mentions the optional parentRoleName to place a role under an existing one. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites beyond the implied hierarchy context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so description need not repeat that. The description adds return type ('Returns the CSV content as a string') and defaults, but it introduces conflicting parameter names (soql, includeHeader, maxRecords) versus the schema's query, includeHeaders, limit, and it omits the format parameter entirely, creating confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively brief and front-loaded with the main purpose. But the inline parameter documentation is redundant and inconsistent with the schema, adding noise rather than clarity. It could be shortened to reference the schema parameters instead of duplicating them with different names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is missing semantics for the 'format' parameter, which can output JSON or CSV per schema, yet the description only mentions CSV. It also does not explain how the returned string is structured or provide pagination details, and the parameter naming mismatch further reduces completeness. The absence of an output schema makes these omissions more significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, giving baseline 3. However, the description's parameter list uses names that don't match the schema: 'soql' vs 'query', 'includeHeader' vs 'includeHeaders', 'maxRecords' vs 'limit'. It also fails to mention the 'format' parameter. This actively misleads the agent and decreases clarity below baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Exports Salesforce records') with a specific format ('as CSV data') and method ('using a SOQL query'). This distinguishes it from sibling tools like sf_query_records (which likely returns structured query results) and sf_bulk_import_records (import-focused).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use cases ('data extraction, backup, or analysis') and an alternative for large datasets ('For very large exports (>50k records), use sf_bulk_import_records with operation='query' instead'). However, it does not contrast with sf_query_records or specify when JSON format (from schema) is preferred over CSV.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide read-only/destructive/idempotent hints, and the description does not contradict them. The description adds minimal extra behavioral context—it doesn't mention what happens on re-sharing or the effect on existing shares—but this is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action ('Shares...'), and contains no unnecessary information. It is concise and well-structured, earning a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, nested objects), the description covers the core purpose and usage context. However, the territory inaccuracy and lack of clarity on the accessLevel parameter relationships leave gaps. The schema covers most parameter details, so the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. However, the description incorrectly includes 'territories' as a valid recipient type, which contradicts the schema enum and could mislead the agent. It also fails to clarify the relationship between the top-level 'accessLevel' shorthand and the per-recipient accessLevel in the shareWith array, making the parameter semantics less reliable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Shares a Report or Dashboard folder' and sets access levels, which is specific and distinguishes it from folder creation tools. However, it lists 'territories' as a recipient type, which is not in the schema enum (only Role, Group, User, RoleAndSubordinates), making the scope partially inaccurate and reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use after creating a folder to grant team members access,' giving a clear sequential use case. It does not explicitly contrast with alternatives, but the context is sufficient for this focused tool. No misleading guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds helpful behavioral detail: 'finds the latest BotVersion for the specified bot and adds the transfer dialog.' Annotations already indicate write/idempotent/non-destructive, so this adds operational context. However, it lists triggers (agentRequested, noResponse, fallback) that contradict the schema enum (agentRequested, unrecognized, maxErrorCount, custom), which could mislead about actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with a clear purpose sentence, parameter list, and additional notes. However, the parameter list repeats schema information and contains inaccuracies, making it less concise in a quality sense. It is not overly verbose, but the misinformation reduces effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, prerequisites, and side effect (updating latest BotVersion). However, the inaccurate parameter details and lack of mention of return/error behavior (no output schema) leave gaps. For a tool with this complexity, it is mostly complete but with significant caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, so baseline is 3, but the description introduces incorrect parameter semantics. It states 'Triggers: agentRequested, noResponse, fallback' and 'Actions: TransferToQueue', while the schema allows triggers 'unrecognized', 'maxErrorCount', 'custom' and actions 'TransferToQueue', 'EndChat', 'SetVariable'. This misleading info degrades the value added. It does correctly map botName and transferToQueueName to DeveloperName/Queue API name, but the errors outweigh that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Configures an Einstein Bot to transfer conversations to a human agent queue when escalation conditions are met.' It names specific resources (BotVersion, Transfer dialog) and distinguishes from siblings like sf_create_einstein_bot which creates bots, not configures routing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('when escalation conditions are met') and an explicit prerequisite: 'The bot must already exist (created via Setup or sf_create_agent).' It does not explicitly contrast with alternative tools, but this is sufficient guidance for when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly=false, idempotent=true, and openWorld=true, but the description does not explain idempotency behavior (e.g., duplicate handling) or permission requirements. It only says 'Creates,' which is already implied by the annotations, adding little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the main purpose, then adds usage context and parameter guidance. It is readable and without unnecessary filler, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the what and when well, but it does not mention return values (no output schema present) or any prerequisites. For a moderate-complexity creation tool with full schema coverage, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for all parameters. The description reiterates directive examples but does not add new semantic details beyond what the schema already contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it creates a Content Security Policy trusted site, with a specific verb and resource. It also explains the purpose (allowing LWC/Visualforce to load external resources) and distinguishes it from other creation tools by its focus on CSP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool: when LWC uses external JavaScript libraries, fonts, images, or APIs. However, it does not explicitly mention alternative tools like Remote Site Settings, so it lacks an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the mutation safety profile. The description adds only the '__c' naming rule and 'existing object' scope, which are also present in the schema or purpose, so it contributes little new behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and avoids redundant detail already present in annotations or schema. It is appropriately succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 18 parameters, nested objects, and type-specific requirements, the description is far too sparse. It fails to warn that Picklist requires picklistValues, Lookup/MasterDetail requires referenceTo, or that Number fields need precision/scale. No output schema exists, so the description should help guide correct invocation; it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats the '__c' suffix (already in fieldName's pattern) and lists field types (already in the type enum), adding no new meaning beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a custom field on an existing Salesforce object, using a specific verb and resource. It distinguishes itself from sibling tools like sf_create_custom_object by focusing on fields, and the '__c' suffix constraint adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is the general tool for creating custom fields ('Supports all field types') but does not explicitly mention when to use it versus specialized alternatives like sf_create_formula_field or sf_add_picklist_values. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds one behavioral note: 'After creation, get the deployment code snippet from Setup → Embedded Service Deployments,' which tells users where to find the result. However, it does not disclose deeper behaviors like required permissions, potential side effects, or whether the deployment is immediately active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear opening sentence, then parameter details broken into sections, and a final note about retrieving the snippet. It is concise with no filler, though the channelType wording could be tightened to align with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and mentions post-creation steps, but with 11 parameters and no output schema, it leaves gaps: it does not explain the return value, prerequisites (e.g., needing to create a chat button or messaging channel first), or the full range of channelType enums. The conditional requirements are partially explained but could be more precise.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 73%, and the description compensates for some undocumented parameters by explaining channelType choices (Chat vs Messaging), required parameters per type, and branding options. However, it does not describe the 'label' or 'description' parameters, and it introduces a potential mismatch: the schema enum for channelType is 'LiveAgent'/'MessagingChannel'/'EmbeddedMessaging' while the description says 'Chat'/'Messaging' and omits 'EmbeddedMessaging' entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('Creates') and resource ('Embedded Service deployment / EmbeddedServiceConfig'), and explains what it does: bundles a chat button or messaging channel into a web snippet. This distinguishes it from sibling tools like sf_create_chat_button or sf_create_messaging_channel by focusing on the deployment configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when creating an Embedded Service deployment) and explains parameter requirements for Chat vs Messaging, but it does not explicitly state when not to use it or mention alternatives. The guidance is helpful but not fully explicit about trade-offs versus using other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds lifecycle context (must be assigned to agents) and outlines use cases, but it does not discuss permissions, duplicate-handling behavior, or the response format. This gives some extra context beyond the annotations but leaves important behavioral details unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences with a bulleted list of use cases. The main purpose is front-loaded, and every sentence contributes value. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, use cases, and a recommended next step. Annotations handle the safety profile. However, it lacks parameter meanings and expected output or error behavior, which is notable for a tool with 3 parameters and no output schema. Overall, it is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only skillName has a description). The description text does not explain what 'label' or 'description' parameters represent, nor does it clarify the difference between label and skillName. With such low schema coverage, the description was responsible for compensating, and it fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Creates a Skill that can be assigned to service agents.' It then specifies two distinct use cases (OmniChannel routing and Field Service Lightning), which helps differentiate it from sibling create_* tools like sf_create_service_channel or sf_create_routing_configuration. The title also reinforces the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when this tool is relevant: for skill-based routing and Field Service Lightning. It also gives a concrete next step ('assign it to agents with sf_assign_skill_to_agent'), which implies the tool is for creation only. However, it does not explicitly mention when not to use it or name an alternative tool, so it falls short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds useful return-value context (status, errors, stack traces, coverage) but contains a factual discrepancy: it states limit default 100 while schema says 200. This misrepresentation reduces trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably short and front-loaded, but the inline parameter lines duplicate schema fields with errors, adding confusion rather than clarity. The structure could be tighter by omitting repeated parameter info or correcting it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the main purpose, filters, and return fields, and annotations handle safety. However, it misses testRunId guidance, misstates defaults/outcome options, and with no output schema these gaps are more impactful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3, but the description adds negative value by contradicting schema: 'outcome' omits CompileFail and says 'omit for all' while schema default is 'all', and limit default is wrong. It also ignores testRunId entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies the verb 'Retrieves' and resource 'Apex test results' from recent test runs via the Tooling API, and lists the types of information returned. This distinguishes it from siblings like sf_run_apex_tests (which runs tests) and sf_check_code_coverage (which focuses on coverage).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use after test runs, and the testRunId parameter references sf_run_apex_tests, implying the connection. However, it does not explicitly state when not to use or name alternatives, so it loses a point for lack of explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds context by specifying the content of the returned configuration (type, field mappings, filter criteria), but it does not disclose the return format, error behavior, or any side effects. With annotations in place, this is acceptable but not enriched beyond the basics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, then elaborates with specific content types. Every word adds value; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with no output schema and good annotations, the description is nearly complete. It explains what is retrieved, and the absence of optional parameters or complex behaviors means little is missing. A return format hint would elevate it, but given the simplicity, the coverage is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters: dataRaptorName is described as 'API name of the DataRaptor to retrieve'. The description adds no further detail about parameter semantics, such as case sensitivity or uniqueness. Since schema coverage is full, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Retrieves the configuration of a DataRaptor interface' and specifically lists its contents (type, field mappings, filter criteria). This distinguishes it from sibling creation/import/export tools and other get tools targeting different resources. The verb+resource combination is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention related tools like sf_create_dataraptor or sf_import_omnistudio_component, nor does it state any prerequisites or context where this getter is preferred. The description implies a read operation but offers no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds no further behavioral detail (e.g., side effects, permissions, reversibility). With annotations covering the safety profile, this is acceptable but minimal, scoring 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The two main sentences are concise and useful. The subsequent parameter list duplicates schema information, adding redundancy. This minor waste prevents a perfect 5, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with no output schema, the description sufficiently explains purpose and usage. It lacks prerequisite or side-effect details, but given the tool's simplicity, it's adequate. Scoring 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions identical to those repeated in the description. Since schema coverage is 100%, the description adds no extra semantic value beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Promotes a DevOps Center work item to a specific pipeline stage by ID.' It specifies the resource (DevOps Center work item) and mechanism (by ID). However, it doesn't distinguish from the similarly named sibling sf_devops_promote_work_item, so it misses the full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use: 'Use to move work items forward in the pipeline when you know the exact target stage.' This provides clear context, but there are no exclusions or explicit alternatives mentioned, landing at 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the annotations, such as sending a password-reset email and the ability to disable email via sendEmail=false. Annotations already indicate a non-readonly operation, so the description adds useful side-effect information without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the main purpose. Some redundancy exists (e.g., email sending is mentioned twice), but overall it is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers purpose, usage, and parameters adequately. However, the userId discrepancy with the schema and the lack of information about the actual outcome (e.g., whether the password is reset to a temporary value) leave some gaps, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% description coverage, the description introduces 'userId' which is not in the schema and states 'at least one required' while the schema marks 'username' as the sole required field. This misinformation undermines the clarity that the schema already provides, making the parameter semantics confusing rather than helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool resets a Salesforce user's password and sends a password-reset email, which distinguishes it from sibling tools like sf_freeze_user or sf_update_user. However, it mentions 'username or user ID' while the schema only includes 'username', introducing ambiguity about the actual input scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage context: 'Use when a user is locked out or needs to set a new password.' This helps the agent decide when to invoke the tool. It does not mention alternatives or exclusions, but the context is clear enough for this simple operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation with no destructive or idempotent behavior. The description adds useful context about the SObject used and the resulting visibility effect. It does not contradict annotations, so no score 1. The role value mismatch is more a parameter semantics issue than a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loads the action, but the parameter list duplicates schema info and includes inaccurate details. It is not as concise as it could be, and the inaccurate enum list adds noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description does not mention return values, prerequisites (e.g., Enterprise Territory Management enabled, user/territory existence), or failure modes. The parameter contradictions further reduce completeness. For a write operation with no output schema, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100%), giving a baseline of 3. However, the description actively contradicts the schema: it lists roleInTerritory allowed values as 'Salesperson', 'Manager', 'BusinessUser' while the schema enum is 'Salesperson', 'AccountManager', 'Owner'. It also mentions 'userId' as an alternative to 'username', which does not exist as a parameter. This could mislead the agent into sending invalid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool assigns a user to an Enterprise Territory Management territory via the UserTerritory2Association SObject. It uses a specific verb and resource, and the inclusion of the SObject distinguishes it from other assign tools like sf_assign_skill_to_agent or sf_assign_presence_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context by explaining that assigned users gain visibility into accounts in the territory. It does not explicitly mention alternatives or exclusions, but the use case is well implied. This meets the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds the behavioral context of creating a matrix and mapping inputs to outputs, but does not disclose potential side effects, error handling, or prerequisites. It does not contradict the annotations, and with annotations covering the safety profile, this is an adequate but not rich disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with a clear opening sentence, use cases, parameter explanations, and an example. It is well-structured and front-loaded, though the inaccurate row structure slightly muddies the parameter section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, key parameters, and an example, but omits required parameters like label and matrixName. It also provides conflicting row structure and does not explain return values or duplicate behavior. Without an output schema, these gaps make the description incomplete for a tool with 6 parameters and 4 required fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description inaccurately describes inputVariables as a 'list of input variable names' while the schema requires an array of objects with a 'name' and optional 'dataType'. Moreover, it describes rows as '{ inputs: {...}, outputs: {...} }', but the schema defines rows as flat objects with additional string properties. These structural contradictions meaningfully mislead an agent about how to populate the parameters, outweighing the correct semantic hints about columns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates a Calculation Matrix') and explains its function (rule-based lookups, mapping input combinations to output values). It names the specific resource and provides concrete use cases (pricing, eligibility, scoring), distinguishing it from sibling tools like sf_create_calculation_procedure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it is 'useful for pricing, eligibility, scoring, and decision tables', giving clear when-to-use context. However, it does not explicitly mention alternatives or when NOT to use this tool (e.g., when a Calculation Procedure would be more appropriate), so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no context about idempotency despite the idempotentHint=true annotation, which is unusual for a create operation and needs explanation. It also doesn't clarify potential side effects (openWorldHint) or mention what happens on duplicate record names. Annotations provide only the basic safety profile, so the description should carry more weight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by a concise explanation and an example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should mention what the tool returns (e.g., success message or record ID) and any constraints like unique record names or required permissions. It covers purpose and example but misses these operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-described. The description reinforces the typeName example but does not add meaningful detail about label vs. recordName or how the values array maps to fields. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates') and resource ('record within an existing Custom Metadata Type'), with an example typeName. It clearly distinguishes from the sibling tool sf_create_custom_metadata_type by specifying the type must already exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: records store configuration values for Apex, Flows, and formulas, indicating appropriate use cases. However, it does not explicitly mention when not to use it or point to sf_create_custom_metadata_type as an alternative for creating the type itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description's 'Creates' is consistent with readOnlyHint=false, and no contradiction exists with the idempotentHint. It adds useful context about escalation rule behavior (reassignment, notifications, business hours) but does not detail operational side effects like uniqueness requirements or validation errors, which are left to the annotations and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler, front-loading the core purpose in the first words. The second sentence adds relevant behavioral context without redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested schema (ruleEntries, escalationActions, criteriaItems), the description provides a useful high-level overview but does not explain how to structure rule entries or the relationship between formula and criteriaItems. However, the schema itself is fully self-documented, so the description is adequate though not enriched with examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, meeting the baseline for this dimension. The description's mention of 'business hours' and 'configurable start date' merely echoes schemas descriptions for businessHours and escalationStartDate, adding no new semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates an Escalation Rule for Cases,' clearly stating the verb, resource, and scope. It further explains the rule's behavior (auto-escalating unclosed cases with reassignment and notifications), which distinguishes it from sibling rule-creation tools like assignment or workflow rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what escalation rules do, implying when to use this tool (when time-based case escalation is needed), but it does not explicitly name alternatives or exclusion criteria. There is no guidance such as 'use sf_create_assignment_rule for criteria-based assignment,' so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating (readOnly=false) but non-destructive tool. The description adds behavioral context about the app structure and navigation choices but does not disclose side effects, error conditions, or idempotency behavior beyond the idempotentHint annotation. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary purpose, then key choices, then usage statement. No redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has 10 parameters and two array-typed nested objects, the description only covers two parameters and the general use case. It omits mention of utilityItems, setupExperience, and the two boolean flags, which may be needed for complete invocation. The schema partially fills gaps but the description alone is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 70% of parameters with descriptions. The description clarifies navItems with examples ('objects, home, reports, etc.') and explains navType, but much of this overlaps with schema descriptions. It does not add meaning for other parameters like utilityItems or setupExperience.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates') and clearly identifies the resource ('Lightning App in Salesforce') with distinctive details (branded navigation container, custom navigation bar, utility bar, logo). However, it does not explicitly differentiate from the sibling tool sf_create_custom_application, which could be confused as an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use when a user wants a custom app experience for a specific team or use case.' It does not list exclusions or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, idempotent, non-destructive operation. The description adds that it creates an action and sets a field to a literal, formula, or null, providing contextual behavior. However, it does not disclose potential caveats like required permissions or metadata component creation, though annotations diminish the need for that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action verb, and every word adds value. No redundant or inflated content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8-parameter schema and good annotations, the description covers purpose, usage context, and value options. It does not explain return values (no output schema) or prerequisites, but this is acceptable for a straightforward create operation with detailed schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 meaningful grouping by stating that the field can be set to 'a literal value, formula result, or null', which directly maps to the parameters literalValue, formula, and nullValue. This enriches parameter understanding beyond the individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Creates a Workflow Field Update action that can be referenced by Approval Processes, Workflow Rules, or Flows.' This is a specific verb+resource, and it also mentions the value-setting behavior (literal, formula, null). It does not explicitly differentiate from the sibling 'sf_create_field_update', but the mention of referencing contexts provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage context by noting the action can be referenced by Approval Processes, Workflow Rules, or Flows, but it does not explicitly state when to use this tool versus alternatives like sf_create_field_update or sf_create_workflow_rule. The guidance is embedded but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the operation is not read-only (readOnlyHint=false) and not idempotent, but the description adds some value by specifying 'using the SF CLI' and noting the wait parameter for installation duration. It does not disclose potential side effects, required authentication scope, or what happens on failure, but the annotations already flag the write nature, so a moderate score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a clear, concise summary, but then redundantly restates all four parameters that are already present in the schema with identical descriptions. This duplication wastes space and reduces the efficiency of the text, though it remains short overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation, parameter purposes, and default behavior (targetOrg defaults to SF_ALIAS env var). Since there is no output schema, it does not mention return values or output format, which is a gap, but the tool's operation is straightforward and the description is generally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats the parameter list that is already fully documented in the input schema (100% coverage). It adds no new semantic meaning beyond what the schema provides, so basing on the schema coverage gives a 3, which is the neutral baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('installs'), a resource ('a package version'), and a target ('into a target org'), making the tool's purpose unmistakable. It also clearly differentiates from siblings like sf_uninstall_package and sf_create_package_version by focusing on the install action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: installing package versions into target orgs, and notes it supports both managed and unlocked packages. However, it does not explicitly mention alternatives or when not to use this tool (e.g., for uninstalling), though the sibling list makes that inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-destructive, idempotent operation. The description adds context that activation enables launching from specific surfaces, but it does not disclose potential side effects such as versioning implications or whether activation can be reverted. It neither contradicts the annotations nor adds significant behavioral detail beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The first sentence states the action and outcome; the second explains the identifier. Every word contributes to understanding the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with only 3 parameters and no output schema, the description covers the core purpose and identification. Combined with the annotations (non-destructive, idempotent), the agent has enough context to decide when to invoke it. It could mention what happens upon activation (e.g., return value, version behavior), but given the tool's simplicity, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides basic descriptions for type and subType, but language only has a default value with no description. The description's statement 'Identified by Type + SubType + Language' adds meaning by clarifying that these three parameters together form a composite identifier, which is useful. However, it does not provide examples or explain valid values, so it only partially compensates for the schema's gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('activates') and clearly identifies the resource ('OmniScript') and the outcome (can be launched from FlexCards, Experience Cloud, or standalone pages). It also specifies the unique identifier (Type + SubType + Language), which distinguishes this tool from sibling activation tools like sf_activate_flow and sf_activate_flexcard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need to make an OmniScript launchable from those surfaces. However, it does not explicitly mention alternatives, when not to use it, or any prerequisites (e.g., the OmniScript must exist). The context is implied rather than clearly contrasted with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly=false, destructive=false, idempotent=true, and openWorld=true. The description adds functional detail but does not disclose additional behavioral traits like deployment requirements, overwrite behavior, or authorization needs. It is minimally adequate given existing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into three parts: a clear definition, a bullet-like breakdown of steps, and a usage note. Each sentence serves a purpose, and the formatting aids readability, though it is slightly longer than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested steps array and no output schema. The description thoroughly covers the steps but omits guidance on top-level parameters like 'label' and 'description'. The step type mismatch with the schema creates a notable gap, and the overall description is not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters with descriptions, and the description compensates by thoroughly explaining the steps array structure. However, there is a significant mismatch: the description mentions step types 'MatrixLookup', 'Formula', and 'Assignment' while the schema enum is 'Matrix', 'Expression', 'Loop', and 'Condition'. This inconsistency could mislead the agent into passing invalid enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Calculation Procedure using a specific verb and resource. It distinguishes from siblings like sf_create_calculation_matrix and sf_create_integration_procedure by emphasizing orchestration of multi-step calculations and providing concrete use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context with the sentence 'Use Calculation Procedures to build complex pricing engines, eligibility calculators, or multi-factor scoring systems.' It does not explicitly name alternatives or state when not to use it, but the use cases give strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a write operation (readOnlyHint=false), non-destructive, and idempotent. The description adds the outcome that the app appears in the App Launcher and notes the use of the Metadata API. This adds some context but does not disclose deeper behaviors like what happens if an app with the same name already exists, which is relevant given the idempotent hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first sentence states purpose, second lists supported types, third summarizes key parameters and outcome. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema), the description provides sufficient context for most use cases, covering purpose, key options, and post-creation outcome. It does not mention return values or behavior on conflicts, but the rich schema and annotations offset some of that need. A small gap exists in not clarifying the distinction from the sibling sf_create_lightning_app.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 some parameter concepts (tabs, form factor, utility bar) but does not add new meaning beyond what the schema already specifies. It adds minimal extra value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a Lightning Application (App) in the Salesforce org via the Metadata API,' using a specific verb and resource. It distinguishes itself from sibling tools by mentioning the Metadata API and the specific configuration options (tabs, form factor, utility bar), which clearly differentiates it from other create tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by listing supported navigation types and configurable components, implying when to use it. However, it does not explicitly state when not to use it or mention alternatives (e.g., sf_create_lightning_app), so it falls short of providing explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that this is a mutation (readOnlyHint=false) and idempotent (idempotentHint=true). The description adds no further behavioral details such as whether existing templates are overwritten, deployment requirements, or side effects. It does not contradict the annotations, but it also doesn't go beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: an opening purpose statement followed by a clean parameter list. It is concise and front-loaded, though the parameter list partially duplicates schema descriptions, making it slightly verbose for an MCP tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters and the creation purpose are covered, but there is no output schema and the description does not mention what the tool returns or any post-creation steps (e.g., deployment). For a mutation tool with several parameters, the lack of return-value info is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all seven parameters, so the schema carries the heavy lifting. The description repeats each parameter with minor additions like 'unique API name' and 'the Salesforce object this template generates documents for,' but these add only marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Creates an OmniStudio Document Generation configuration' and explains it 'links a document template to a data source for automated document creation.' This specific verb+resource combo distinguishes it from sibling tools like sf_create_dataraptor or sf_create_omniscript.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining the purpose (automated document creation) and the object/template/data source relationship. However, it does not explicitly mention when to use this tool over alternatives or any exclusions, so it lacks the explicit 'when-not' guidance that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds conceptual context but no additional behavioral details such as required permissions, side effects, or return behavior. No contradiction with annotations was found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and informative, but the second paragraph lists parameters that duplicate the schema descriptions, adding redundancy. While not overly long, the parameter list does not earn its place given the comprehensive schema, making it less efficient than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with a detailed input schema, the description provides sufficient context about what an Entitlement Process is and its key fields. There is no output schema, so return values are not expected. Some optional parameters like exitCriteriaBooleanFilter are not mentioned, but the schema covers them, so overall completeness is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description repeats some parameter names and adds minor clarifications (e.g., entryStartDateField as 'field that starts the SLA clock'), but this is marginal beyond the schema, aligning with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 a specific verb and resource: 'Creates an Entitlement Process (SLA policy)'. It explains the domain context of SLA enforcement and time-based milestones, which distinguishes it from similar create tools like sf_create_approval_process or sf_create_milestone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining that entitlement processes automate SLA enforcement, indicating when this tool is relevant. However, it does not explicitly mention alternatives or exclusion scenarios, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the write nature and retry safety are known. The description adds conceptual context about Milestone Types but does not disclose behavioral details such as duplicate handling, permission requirements, or side effects. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first paragraph is focused and informative, but the second paragraph listing parameters is redundant with the input schema. The description is not overly long but contains unnecessary duplication, so it does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward 4-parameter create tool with no output schema and strong annotations, the description provides adequate conceptual context (what a Milestone Type is and its role in Entitlement Processes). It covers all parameters implicitly and does not need to explain return values, but it could mention prerequisites or idempotency behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are already well-documented in the schema. The description repeats the same parameter names and meanings without adding new information, such as constraints, relationships, or usage examples, beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a Milestone Type' and provides specific context: 'referenced in Entitlement Processes to define SLA checkpoints.' It identifies the exact resource and scope, distinguishing it from generic create tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the use case (Milestone Types for SLA checkpoints in Entitlement Processes), which gives clear context. However, it does not explicitly mention when not to use this tool or compare it to sibling tools like sf_create_entitlement_process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a non-read-only, non-idempotent write operation. The description adds useful context about what a package is ('bundles metadata for distribution') and the difference between managed/unlocked, but it does not disclose potential side effects, authentication needs, or what happens to existing packages. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clearly structured with a purpose-first opening and a parameter list. It is reasonably concise, but the parameter list is redundant given the schema, which slightly reduces efficiency. Overall, every sentence contributes to understanding the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the critical decision between managed and unlocked packages. However, since there is no output schema, the description does not explain what the tool returns or how to verify success. It also omits prerequisites like needing an authenticated org. These are notable gaps for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameters. The description repeats the parameters without adding significant new meaning beyond what is in the schema (e.g., 'path: source path for the package, e.g. force-app' is identical to the schema description). No extra syntax or nuanced details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (creates), the resource (second-generation package), and the method (SF CLI). It also differentiates from siblings by specifying 'managed or unlocked' and explaining the distinction between package types, which helps disambiguate from tools like sf_create_package_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical guidance on when to use each package type ('Managed packages support namespacing and AppExchange listing; unlocked packages support source-tracking without namespacing'), which helps the agent choose the correct packageType. However, it does not explicitly mention when not to use this tool or contrast it with alternatives like sf_create_package_version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent mutation. The description adds that each version captures the current package source state and that versions are promotable/installable, giving some lifecycle context. However, it does not disclose asynchronous behavior, potential errors, or side effects beyond creating a version.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The parameter list is somewhat redundant with the schema, but it is brief and does not distract. Overall, it is well-structured and every sentence contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description carries the burden of explaining the return value and operational behavior. It provides useful lifecycle context but leaves gaps such as what the response contains, how the wait parameter affects polling, and any prerequisites like having an existing package. This is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions (100% coverage). The description reproduces the parameter list with minor elaboration, such as calling installationKey 'optional key to protect the version,' which slightly adds purpose. Overall, the added semantic value is marginal given the schema already describes each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a new version of an existing second-generation package,' using a specific verb and resource. It distinguishes itself from related tools like creating a package or installing/uninstalling packages, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating a version of an existing package and notes that versions can be promoted and installed, providing useful context. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive, idempotent operation. The description adds useful conceptual context ('extend a user's access without changing their profile') but does not disclose additional behavioral traits such as behavior on duplicate fullName, merge semantics, or failure modes. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, purposeful sentences. The first states the core function, the second explains the conceptual value, and the third gives a use-case example. No redundancy or filler; effectively front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity tool with 8 parameters, the description provides adequate context: what it creates, the permission categories, and a realistic use case. The schema and annotations cover the remaining details. Without an output schema, the description could mention return values, but this is not essential for a creation tool given rich structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already fully documented. The description merely lists the same categories (object, field, Apex, user) without adding new meaning or syntax 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a Permission Set' with a specific verb and resource, and enumerates the permission categories (object, field, Apex class, user). It distinguishes conceptually from profile changes, but does not explicitly differentiate from closely related sibling tools like sf_create_permission_set_group or sf_create_muting_permission_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use when you need to grant specific permissions to a subset of users' with a concrete example. The statement 'without changing their profile' implies a when-not scenario, though it does not name alternative tools or explicitly exclude profile-level modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive, idempotent operation. The description adds useful context (Metadata API, session vs org cache, default partition) but does not disclose potential failure modes, deployment delays, or permission requirements beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loaded with the primary action. It includes a brief background on Platform Cache value, but every sentence contributes meaning without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with well-documented schema, the description covers the core purpose and key distinctions. However, it omits details like capacity constraints (org-level limits), behavior on duplicate names, and whether the Metadata API operation is synchronous or requires deployment status checking, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter documented in the input schema. The description adds no new parameter details beyond reinforcing the distinction between session and org cache sizes and the default partition flag, which are already covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates') and identifies the precise resource (Platform Cache partition) via Metadata API. It clearly differentiates from sibling creation tools by focusing on cache partitioning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when this tool is useful (improving app performance via server-side caching) and describes the two cache types. It does not explicitly mention when not to use it or alternatives, but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=false and destructiveHint=false, and the description adds scheduling and batch-processing context. It doesn't discuss whether the created flow is auto-activated, whether deployment is required, or what happens on duplicate names, but it doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose and use cases, followed by a compact parameter list. It avoids filler and is appropriately sized for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the rich schema and annotations, is adequate for understanding what the tool does and how to invoke it. However, it doesn't mention return values or post-create steps like activation (available via sf_activate_flow), and lacks explicit guidance on when to prefer this over sf_create_scheduled_job.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameters. The description's param list mostly paraphrases the schema (e.g., 'object whose records to process') and doesn't add meaning beyond it. It also omits 'connectorTarget' in its summary, but the schema covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates a Schedule-Triggered Flow that runs automatically on a recurring schedule' and specifies the resource and behavior. It also lists use cases (nightly batch processing, periodic data updates, scheduled notifications), which distinguishes it from sibling tools like sf_create_flow and sf_create_scheduled_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use for nightly batch processing, periodic data updates, or scheduled notifications' provides explicit context and typical scenarios. However, it doesn't name alternatives or mention when not to use this tool (e.g., when a simple scheduled Apex job or autolaunched flow would be more appropriate).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false), idempotency (idempotentHint=true), and non-destructiveness (destructiveHint=false). The description adds context about the plain-text body requirement and the need for Visualforce markup, which is useful. However, it does not disclose behaviors like whether an existing template is overwritten, uniqueness constraints, or error handling, beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and then lists the required inputs. Every sentence adds value, and there is no redundancy with the schema. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential inputs and the purpose, and the schema covers all parameters. Given there is no output schema, a note about what happens on success or failure would improve completeness, but it is not strictly necessary for a create operation. The idempotentHint=true might warrant a mention of overwrite behavior, but the overall description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 parameters. The description adds meaning by enumerating the key parameters (template name, subject, recipient type, related entity type, HTML body) and explaining the reason for requiring textBody ('for email clients that don't support HTML'). It also lists the recipient type enum values, reinforcing the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Creates a Visualforce email template in the Salesforce org.' This distinguishes it from sibling tools like sf_create_email_template (generic email template) and sf_create_visualforce_page/component by specifying the resource type as a Visualforce email template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. The sibling list includes sf_create_email_template, which likely serves a simpler use case, but the description does not mention this alternative or any exclusion criteria. The context of requiring plain-text body and Visualforce markup is implied but not framed as selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the specific behavior of moving the work item to 'In Progress' status, which is beyond what annotations provide (readOnlyHint=false, idempotentHint=true, destructiveHint=false). It does not disclose additional details like permission requirements or reversibility, but given the annotations cover the safety profile, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and front-loaded with the action. The parameter line is redundant with the schema, adding slight waste, but overall it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter mutation tool with annotations and no output schema, the description adequately covers the purpose, state change, and usage context. It does not mention edge cases like already-checked-out items, but for this complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description's parameter line ('workItemId: DevOps Center work item ID to check out') exactly repeats the schema description. No additional semantic meaning is provided beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (checks out a DevOps Center work item) and the resulting state change (moving it to 'In Progress' status). This distinguishes it from sibling tools like commit, promote, or create, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when a developer is actively starting work on a work item. However, it does not explicitly mention alternatives or exclusions (e.g., when not to use it), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and openWorldHint=true, and the description adds the precondition that the class must exist. But it does not disclose what happens after creation (e.g., activation, return value, or side effects), relying on the annotations for basic safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: one for purpose, one for use cases, and one for prerequisite. No redundant text; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no output schema, and moderate complexity, the description provides purpose and use cases but does not explain the creation result or post-creation behavior. The schema covers parameters, but the description lacks an expected outcome or return-value discussion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 11 parameters with descriptions (100% coverage), so the baseline is 3. The description does not add parameter-level detail beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an Apex Email Service, specifying it works via an Apex class implementing Messaging.InboundEmailHandler. This distinguishes it from sibling tools like sf_create_apex_class or sf_create_apex_trigger, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It offers concrete use cases (support cases from emails, parsing content, triggering workflows) and a prerequisite (the Apex class must exist), which gives good context. However, it does not explicitly name alternative tools or state when not to use this tool, so 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a write operation. The description adds the relationship to Record Types and the ordering constraint, providing useful behavioral context. It does not disclose return values or auth requirements, but with annotation coverage this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, with no filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core function and a key dependency, and the schema covers parameters. However, with no output schema, it does not state what is returned upon success, and it does not mention permissions or side effects beyond the stated relationship. Given the tool's moderate complexity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all six parameters with descriptions, so the baseline is 3. The description adds conceptual meaning by mapping values to picklist values and listing the valid objects. It does not add syntax details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Creates' and names the resource 'Business Process' with explicit object types (Opportunity, Lead, Case, Solution). It clearly distinguishes this from sibling create tools like sf_create_approval_process by explaining it defines picklist values for Record Types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear temporal prerequisite: 'Must be created before assigning to a Record Type.' This provides useful context on when to invoke the tool. However, it does not name alternatives or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, idempotent=true, destructive=false), the description adds behavioral details such as routing type behavior, optional bot handling, and the embedding follow-up. This provides useful context without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear purpose sentence, a concise parameter list, and a follow-up note about embedding. It is slightly verbose but each part contributes useful information, with the parameter list serving as a quick reference despite schema redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and minimal annotations beyond safety hints, the description should clarify return values and prerequisites. It covers parameter semantics and the embedding step, but omits expected return data and has the routingType ambiguity, leaving it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds explanations for many parameters, but it misrepresents routingType by listing 'Choice' and 'Queue' while the schema enum defines 'Queue' and 'Bot'. This inconsistency undermines the parameter guidance and could lead an agent to pass an invalid value. Other parameter explanations are helpful but offset by this error.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Live Chat button (LiveChatButton) that can be embedded on websites to start chat sessions. This specific verb+resource distinguishes it from sibling create tools, and the mention of sf_create_embedded_service further contextualizes its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining the routingType options and pointing to sf_create_embedded_service as the next step after creation. It does not explicitly exclude alternatives, but the workflow guidance is sufficient for an agent to know when 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose that the tool is non-read-only and idempotent. The description adds no further behavioral traits such as requiring admin permissions, deployment via Metadata API, or generation of consumer keys and secrets. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core purpose, and contains no unnecessary content. It is well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description clearly explains the tool's purpose and typical use cases, but since there is no output schema, it does not explain what the tool returns. Important operational caveats (e.g., Client Credentials Flow needing Setup UI) exist only in parameter descriptions, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 11 parameters, so the description's mention of callback URLs and OAuth scopes adds little beyond the schema. It reinforces key parameters but does not provide deeper semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Connected App for OAuth authentication, using a specific verb and resource. It distinguishes this tool from siblings by explaining its role in enabling external system integrations via OAuth 2.0.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use context, stating that Connected Apps are required for any external system using OAuth 2.0 and listing common use cases (web, mobile, desktop, server-to-server). However, it does not explicitly mention when not to use it or point out the alternative sf_create_external_client_app.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds context about DataRaptor's operational capabilities (Extract/Transform/Load) but does not discuss tool-level behavior like overwriting existing DataRaptors or permission requirements. This adds some value without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for interface types and field mappings. It is somewhat long but each part contributes to understanding the tool's domain model. Front-loading the main purpose helps, and the bulleted format improves scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema, the description covers the key parameters (interfaceType, field mappings, filterCriteria) and the domain concepts. It does not describe the return value or prerequisites (e.g., OmniStudio licensed), but given the rich annotations and schema, it is fairly complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, and the description adds meaningful semantics beyond the schema: it explains what each interfaceType does, the meaning of sourceField/targetField, dataType, and filterCriteria with examples. This compensates for the moderate coverage and gives the agent practical guidance on filling parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a DataRaptor interface for OmniStudio data transformation' with specific verb+resource. It then details the three interface types (Extract, Transform, Load), making the tool's purpose unambiguous and distinguishing it from retrieval tools like sf_get_dataraptor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what DataRaptors do and the three interface types, implying when this tool is appropriate (for data extraction, transformation, or loading). However, it does not explicitly mention alternatives (e.g., Integration Procedures) or provide 'when not to use' guidance, so usage context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond this, such as merge field support and folder path examples, but does not discuss side effects, overwrite behavior, or permissions. It neither contradicts the annotations nor significantly expands on them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short paragraph of four sentences, each contributing meaningful information without excessive length. It front-loads the core purpose and then adds supporting details. It is appropriately concise for a 13-parameter tool, though not as tight as a two-sentence version.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 13 parameters and no output schema, yet the description only mentions HTML and text template types, omitting the 'custom' and 'visualforce' options in the enum. It also does not explain when to use 'body' versus 'htmlValue', which could lead the agent to send incomplete data. These gaps make the description insufficient for fully confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 valuable parameter-level guidance by providing concrete folder path examples ('unfiled$public/MyTemplate'), merge field syntax ('{!Account.Name}'), and the role of relatedEntityType for object-specific merge fields. These enrich the bare schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an HTML or text email template and specifies its use cases (Workflow Email Alerts, Approval Processes, manual sends). This distinguishes it from related siblings like sf_create_visualforce_email_template, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (workflow alerts, approval processes, manual sends) and implies HTML/text email templates rather than Visualforce. However, it does not explicitly mention alternative tools or exclusions, so it stops short of full comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (not read-only, not destructive, idempotent). The description adds valuable behavioral context beyond annotations, such as support for all return types, full formula language, cross-object references, and complex multi-line formulas. This helps the agent understand the tool's capabilities without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and then expands on capabilities. The second sentence is long but packed with specific useful details (function list, feature support). It is appropriately sized for a tool with complex capabilities, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is fairly complete: it covers return types, formula language features, cross-object references, and multi-line support. It lacks explicit alternatives or prerequisites, but the rich schema and annotations fill in most gaps, making it adequately complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well documented. The description adds context about supported formula functions and return types, but this largely overlaps with the schema's own parameter descriptions. It does not provide significant additional meaning beyond what the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Creates a formula field on any Salesforce object.' It distinguishes itself from siblings like sf_create_custom_field by explicitly focusing on formula fields and enumerating supported return types and formula language features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: this tool is for creating formula fields. However, it does not explicitly state when to use this over alternatives (e.g., sf_create_custom_field for non-formula fields) or provide exclusions. The context is implied but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the component is 'packaged into a deployment zip and deployed via the Metadata API,' adding operational context beyond the annotations. It also explains the effect of isExposed, but does not detail side effects such as overwriting existing components or permissions required. Annotations already indicate a write operation (readOnlyHint=false) and idempotentHint=true, so the additional value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 5 sentences long and front-loaded with the primary purpose. Each sentence adds useful operational detail, though the list of target examples partially duplicates the schema enum. It is slightly verbose but not wasteful, so a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no output schema, the description covers the key workflow: inputs, packaging, deployment, and configurable exposure. It lacks information on error behavior or prerequisites, but given the schema's thorough parameter descriptions, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 8 parameters, so the baseline is 3. The description adds context for targets (e.g., 'Lightning App Builder') and isExposed, but these are already in the schema. It does not add new meaning beyond what the schema provides, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates and deploys a new Lightning Web Component (LWC) to the Salesforce org,' with a specific verb and resource. It distinguishes from siblings like sf_update_lwc and sf_create_aura_component by explicitly mentioning LWC and the deployment step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions on required inputs (HTML template, JavaScript controller, optional CSS) and how to control exposure via targets and isExposed. However, it does not explicitly mention when this tool should be preferred over alternatives like sf_create_lwc_from_requirements or sf_update_lwc, so there's context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety hints (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description is not required to restate them. The description adds value by describing delivery channels and trigger sources, but does not disclose additional details like whether existing types are overwritten or permission requirements. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose, followed by useful context. The parameter list is repetitive relative to the schema but compact and not excessively verbose. It earns its place as a quick reference, though some redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides functional context, usage scenarios, and parameter meanings. It does not mention return values or prerequisites, but these are not critical for a metadata creation tool and the output schema is absent. The richness of the first paragraph compensates for minor omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all four parameters. The description's parameter list essentially restates the schema descriptions (e.g., 'fullName: notification type API name' matches the schema's 'Custom notification type API name'), adding no new semantic meaning. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Creates a Custom Notification Type for sending in-app and mobile push notifications.' It also provides distinctive context (triggering from Flows/Apex/Process Builder, delivery via Bell/mobile app) that clearly differentiates this tool from sibling metadata creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when this tool is relevant by explaining how custom notification types are triggered and where users receive them. It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent can decide 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the resulting object's semantics (users receive all permissions from all included permission sets), but it does not clarify behavior on duplicate creation, error handling, or required permissions. It adds some value but leaves notable behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a front-loaded purpose statement followed by a compact parameter listing. It is slightly redundant with the schema but overall efficient and easy to scan. The structure is clear and every sentence contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with 4 parameters and no output schema, the description is sufficiently complete: it explains what the tool does, when to use it, and gives parameter semantics. It lacks details about response format or edge-case behavior, but these are not critical for tool selection and invocation. The annotations and schema cover the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 restates fullName, label, and permissionSets with brief explanations, but these add little beyond the schema. It does not clarify the optional `description` parameter or any format nuances, so no additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Creates a Permission Set Group that aggregates multiple Permission Sets into a single assignable unit.' This distinguishes it from sibling tools like sf_create_permission_set (which creates a single permission set) and sf_create_muting_permission_set, and explains the core value proposition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context: 'Simplifies administration when users need a combination of permissions.' This informs when to use the tool, though it does not explicitly contrast with alternatives or mention when not to use it. The guidance is clear and direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the create/update behavior, consistent with the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false). It does not add extra details such as permission requirements or whether updating replaces existing field lists, but with annotations covering safety and idempotency, the bar is lower and additional context is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action and purpose in two sentences, followed by a clear parameter list. It is well-structured and free of redundancy, though the parameter list somewhat duplicates the schema descriptions, earning a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so return-value descriptions are unnecessary. It covers all four parameters and explains the three categories of field placements. The only notable gap is the lack of explicit update semantics (merge vs replace), but for an idempotent, non-destructive write operation, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description largely mirrors the schema descriptions, e.g., objectName example and searchResultsAdditionalFields description. It adds minimal extra meaning beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Creates or updates a SearchLayout' for a Salesforce object, specifying the exact resource and action. It further details what the layout defines: fields in search results, lookup dialogs, and lookup filter fields, which distinguishes it from sibling layout tools like page layouts or compact layouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use to customize what columns users see when they search for records or open a lookup dialog,' providing clear when-to-use context. It does not name alternatives or give exclusions, but the intended use is unambiguous and well-differentiated from other create tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds that content is 'deployed via the Metadata API' and that resources are served via a CDN URL, which is helpful context. However, it omits details about return values, behavior if the resource already exists, or what the openWorldHint=true annotation implies. Given that annotations cover safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, then concise context about what static resources are and how content is deployed. There is no redundant or filler wording; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the tool returns upon success or failure—it does not. It also does not address idempotent behavior for existing resources, which is relevant given the idempotentHint. The description covers the purpose and inputs well, but the lack of return-value/overwrite behavior leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with detailed descriptions for all five parameters, including examples and defaults. The description's mention of 'Content is provided as a string' reinforces the content schema but adds no extra semantic value beyond the schema. Baseline 3 is suitable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence uses the explicit verb 'Creates' with the specific resource 'Static Resource' and lists content types (text/JSON/JS/CSS). It clearly distinguishes this tool from the many other sf_create_* siblings by naming the target resource and its intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: 'ideal for JavaScript libraries, CSS stylesheets, JSON configuration, or any other file that needs to be served from Salesforce.' It gives a sense of usage scenarios but does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds context about the tab's UI placement and the requirement for custom object accessibility, but does not disclose additional behavioral traits such as permission needs or update semantics. This adds value but is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the verb and resource, and wastes no words. It efficiently conveys purpose and a key requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description doesn't need to detail return values, and annotations cover safety. However, the tool's schema also supports web and Visualforce tabs (url/page fields), which the description omits entirely. This narrows the tool's capabilities, making the description incomplete for all possible use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameter meanings are already in the schema. The description references 'object API name' and 'motif' with an example, which matches schema entries but adds no new meaning beyond what is already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Creates a Custom Tab for a custom object'), the resource type, and its purpose ('appears in the navigation bar and App Launcher'). It distinguishes this from sibling tools by focusing on custom tabs for custom objects, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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: 'Tabs are required to make custom objects accessible from the UI.' It implies the use case but does not explicitly list alternatives or exclusions, which keeps it just below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, mutating operation, but the description adds specific behavioral details beyond that: the user will receive a welcome email unless suppressed, and the role option requires the DeveloperName. It also notes the REST API mechanism. This provides useful context that annotations do not cover, though it does not mention all side effects or the return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with three sentences that front-load the core action and requirements. Every sentence provides necessary information: the action, the required fields, the prerequisite, optional role assignment, and the email side effect. There is no verbose or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters) and the lack of an output schema, the description is incomplete. It covers the main required fields and one side effect, but it does not describe the return value or success/error behavior. More importantly, the role parameter naming conflict (roleApiName vs. roleName) creates a credibility gap, and the description omits clarification of other parameters' semantics that might be non-obvious. Overall, it is not sufficiently complete for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 11 parameters with descriptions, so the baseline is 3. However, the description introduces a significant discrepancy by referring to 'roleApiName' while the schema parameter is 'roleName'. This could mislead an agent into looking for a non-existent parameter. The description adds little other semantic value beyond the schema, and the naming mismatch undermines its usefulness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Creates a new Salesforce user via the REST API.' It uses a specific verb (creates) and resource (Salesforce user), and the distinct focus on creation distinguishes it from sibling tools like sf_update_user. The description also enumerates the required fields, reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use by listing required fields ('Requires username, lastName, email, and profileName') and stating a prerequisite ('The profile must already exist'). It also clarifies an optional behavior (assigning a role). However, it does not explicitly mention alternatives or when not to use this tool (e.g., for updating existing users), so it lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'A read-only reference tool — does not modify the org,' which reinforces but does not significantly go beyond the annotations. It does add that the tool returns examples, best practices, and guidance, which is helpful, but no additional behavioral details like output format or pagination. This is adequate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. The second sentence clarifies the read-only nature. The parameter listing is redundant with the schema but adds minimal overhead. Overall, it is well-structured and free of fluff, though the duplicated parameter docs could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple reference tool with two parameters and robust annotations, the description is sufficiently complete. It explains what the tool returns (examples, best practices, usage guidance) and the key behavioral trait (read-only). The absence of an output schema is not critical here, though a brief note on the return format would have made it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema already describes both parameters (componentType and includeExampleCode) with examples. The description repeats this information without adding new meaning or clarifying syntax beyond the schema. The baseline of 3 is appropriate because the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns Salesforce Lightning Design System (SLDS) component examples, best practices, and usage guidance for a given UI pattern.' This uses a specific verb ('returns') and identifies the resource ('SLDS component blueprints') and its scope ('for a given UI pattern'). It distinguishes itself from sibling tools like sf_guide_lwc_accessibility by focusing on SLDS component examples and best practices rather than accessibility guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is a 'read-only reference tool' for exploring SLDS components, which implies it should be used when the agent needs examples or usage guidance for a UI pattern. It does not explicitly mention alternatives or exclusions, but the context is strong enough to guide appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return format ('JSON-serialized XML string') and the OmniScript naming convention, but it also lists CalculationMatrix and CalculationProcedure as supported componentTypes while the schema enum omits them, creating conflicting behavioral guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence. The parameter notes are helpful but partially redundant with the schema descriptions, making it slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately explains the return value ('JSON-serialized XML string'). Annotations cover safety, and the schema documents all parameters. Minor gaps include error behavior and the componentType enum inconsistency, but overall the description is adequate for a read-only export tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the useful 'Type_SubType_Language' format hint for componentName, which the schema lacks. However, the componentType list in the description contradicts the schema enum by including CalculationMatrix and CalculationProcedure, undermining reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Exports an OmniStudio component's metadata as a JSON string,' and names concrete use cases (backup, version control, migration). This clearly distinguishes it from sibling tools like sf_import_omnistudio_component, sf_get_omniscript, and the various create/update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states explicit contexts for use: 'for backup, version control, or migration to another org.' It does not name alternative tools or provide when-not-to-use guidance, stopping short of a 5, but the intended usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, open-world, idempotent, and non-destructive, so the description only needs to add extra context. It does add that the tool returns all or specified fields and accepts 15/18-character IDs, but it omits error behavior, permission requirements, or field-level security, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The parameter list is somewhat redundant with the schema but is clearly formatted and does not become verbose. Overall it is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only single-record retrieval, the description covers the essential behavior, parameters, and expected use. The schema fully documents inputs, annotations cover safety, and no output schema is required. It is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats the parameter names and basic purpose (e.g., objectApiName, recordId, fields) but adds no meaningful detail beyond the schema's own descriptions, which already include examples and the 'empty means all fields' note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieves') and resource ('single Salesforce record by its 15 or 18 character record ID'), which clearly distinguishes this from sibling tools like sf_query_records or sf_search_records. The scope is unambiguous and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you have a Salesforce record ID and need a single record. It does not explicitly name alternatives or exclusions, but the 'single record by ID' framing provides sufficient context to differentiate from query/search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces this with 'does not modify the org'. It also describes the output components (concept mappings, key differences, optional scaffold), but does not disclose additional behavioral traits such as error conditions, prerequisites, or rate limits. With annotations covering the safety profile, the description adds some but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with two sentences covering purpose and safety, followed by inline parameter definitions. It is well-structured and front-loaded, but the parameter definitions duplicate the schema descriptions, slightly reducing efficiency. Overall, it earns its place without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analysis tool with two parameters and no output schema, the description adequately covers what the tool does, what it returns (guide with mappings, differences, scaffold), and its non-destructive nature. It does not mention prerequisites such as the component existing, but the annotations and schema fill most gaps, making it sufficiently complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for both parameters (100% coverage), and the description repeats them almost verbatim (e.g., 'includeScaffold: whether to generate equivalent LWC template, JS, CSS, and meta files'). The description adds no new meaning beyond what the schema already documents, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Analyzes an Aura component and returns a comprehensive migration guide', specifying both the action and the resource. It distinguishes itself from sibling tools like sf_create_lwc or sf_guide_lwc_accessibility by focusing specifically on Aura-to-LWC migration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes 'A read-only advisory tool — does not modify the org', providing clear context that this is for analysis/migration guidance rather than direct modifications. However, it does not explicitly name alternative tools or state when not to use it, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value by explaining that SOSL uses the search index and is faster than SOQL, plus it details searchGroup and limit defaults. This goes beyond the structured fields, though it does not describe return format or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence followed by a parameter list. It is not overly verbose, but the inclusion of a non-existent parameter (searchGroup) means not every sentence earns its place, preventing a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, gives context on the search mechanism, and includes parameter examples. However, it fails to mention the objectTypes alias, includes a phantom searchGroup parameter, and does not explain the return structure. For a search tool with no output schema, this leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides examples and defaults for objects and limit, but it references 'searchGroup' as a parameter that does not exist in the input schema. It also omits 'objectTypes' which is present in the schema as an alias. This introduces confusion and reduces the reliability of the parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches across multiple Salesforce objects using SOSL, a specific verb and resource. It also differentiates from sibling tools by noting SOSL is faster than SOQL for cross-object text searches, which distinguishes it from sf_query_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly compares SOSL to SOQL, implying when to use this tool (cross-object text searches) and naming the alternative (SOQL). However, it does not explicitly state when not to use it or mention prerequisites, so it lacks the full 'when-not' guidance for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds specificity by stating 'Removes all metadata delivered by the package' and the target scope (second-generation package), but does not disclose additional behavioral details like irreversibility, authentication requirements, or what happens to dependent components. The added value over annotations is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences stating purpose and usage, followed by a short parameter list. It is front-loaded with the primary action and use cases. The parameter list slightly duplicates the schema but is not excessively verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema, the description covers the main purpose, when to use it, what is removed, and parameter meanings. It lacks details like return values or post-conditions, but given the annotations and simple parameter set, it is adequately complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description's parameter list (packageId, targetOrg, wait) exactly duplicates the schema descriptions, including the SF_ALIAS env var default. No new semantic information is added beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uninstalls a second-generation package from a target org using the SF CLI, and specifies the effect: 'Removes all metadata delivered by the package.' This is a specific verb+resource action that is distinct from siblings like sf_install_package or sf_create_package.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use before reinstalling a broken package, or to clean up a package no longer needed.' It does not explicitly mention when not to use it or name alternative tools, but the use cases are specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a mutating, idempotent, non-destructive operation. The description adds the outcome (invocability) but does not disclose additional behavioral traits like permissions or status transitions. This is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and no redundant details. The second sentence is a fragment but still concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple activation operation, the description covers purpose and identification, with annotations covering safety traits. It could be more complete by noting any prerequisites (e.g., the IP must exist and be in draft status), but overall it is sufficient for an agent to understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types and constraints with 0% description coverage. The description adds the key semantic that procedureName and subType together form the composite identifier, which is helpful, but it does not explain the meaning of 'subType' or provide format examples beyond the schema's length constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Activates an Integration Procedure') and the intended effect ('so it can be invoked from OmniScripts, FlexCards, and APIs'). It also distinguishes this tool from related siblings like get/update/create by specifying activation purpose and the identifier fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (making an IP invokable) and provides context that the tool is for activation. However, it does not explicitly name alternatives or exclusions, such as 'use update_integration_procedure to modify logic instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey the read/write nature (readOnlyHint: false) and idempotency (idempotentHint: true), so the description does not need to restate those. It adds the prerequisite that the change set must already exist and indicates broad metadata type support, which is helpful. However, it does not describe what happens if the change set is missing, whether duplicate additions are ignored, or if the operation appends or replaces components.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action and immediately followed by usage context. The list of metadata types is illustrative without being exhaustive, and every sentence earns its place. There is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of the tool, the description is complete enough: it states what it does, when to use it, and what inputs are relevant. It lacks return-value details, but there is no output schema and the focus is on a mutation action. The sibling set includes sf_create_outbound_change_set, and the description correctly positions this tool as the follow-up step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptions for changeSetName, components, name, and type. The description adds minor context like 'existing' and 'by change set name', but does not meaningfully enrich parameter semantics beyond the schema. The baseline of 3 is appropriate because the schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Adds' and the resource 'one or more metadata components to an existing Outbound Change Set by change set name'. It also enumerates common metadata types, making the scope concrete. This distinguishes it from siblings like sf_create_outbound_change_set, which creates a change set rather than populating one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use after creating a change set', which gives a clear temporal context and situates it in the deployment workflow. It does not explicitly name alternative tools for deployment or creation, so it stops short of a full 5, but the guidance is practical and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write behavior (readOnlyHint=false) and non-idempotency. The description adds useful context about the prerequisite and notification effects. However, it doesn't clarify behavior for adding roles vs. users, duplicate members, or error handling when the queue/user doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the core action and provides only essential context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no output schema and moderate parameters, the description covers the purpose, prerequisite, and practical implications. It lacks details on edge cases (duplicate members, nonexistent queue/user) but is otherwise sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description mentions 'by username and queue DeveloperName' but doesn't add meaningful detail beyond the schema. It doesn't clarify whether users and roles can be combined or how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Adds a user to an existing Queue (GroupMember SObject) by username and queue DeveloperName.' It clearly identifies the resource (Queue/GroupMember) and the method, distinguishing it from sibling tools like sf_create_queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key prerequisite: 'The queue must already exist (create via sf_create_queue).' This gives clear context on when to use the tool and points to an alternative for creation. It also explains the downstream effect (record assignment and notifications), aiding decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the write nature is covered. The description adds useful context about creating a commit record and recording the message for audit tracking, but it doesn't disclose potential side effects like work item status changes or relationship to checkout/promote flows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences followed by a parameter list. It is front-loaded with the main action and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter write tool with no output schema, the description covers the core purpose and parameters adequately. It could mention preconditions (e.g., having changes checked out) or what happens after the commit, but given the low complexity, the description is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the two parameters, and the descriptions provided in the tool description simply restate the schema's parameter descriptions without adding extra semantic detail. Baseline 3 is appropriate because the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Commits changes for a DevOps Center work item' and clarifies the mechanism ('by creating a commit record associated with the work item'). This clearly distinguishes it from siblings like checkout, promote, or create pull request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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: you commit changes for a DevOps Center work item. It doesn't explicitly name alternatives or exclusions, but the context is sufficiently clear given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate idempotency and non-read-only behavior. The description adds that it uses the Metadata API and can create or update, but doesn't disclose additional behavioral nuances like the irreversibility of activation (which is only in the schema). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the action immediately stated. Every phrase adds value—the verb, resource, API method, and key configurable aspects—without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters and no output schema, the description provides a useful overview of the tool's capabilities, while the rich schema and annotations cover the detailed semantics. It could mention return values or activation warnings, but these are either obvious from the create/update context or present in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% detailed descriptions of all 14 parameters, so the description doesn't need to add much. It lists high-level categories (submitters, steps, approvers, entry criteria, actions) that map to parameters, but adds no new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Creates or updates' and names the resource 'Salesforce Approval Process' via 'Metadata API', clearly distinguishing it from sibling tools like sf_create_validation_rule or sf_create_workflow_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly identifies the tool's domain (approval processes) and the operation (create/update), making it obvious when to use it. However, it doesn't explicitly mention alternatives or exclusion conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, idempotent, non-destructive operation. The description adds the detail that it returns the .app file content, which is useful. However, it leaves ambiguity about what 'scaffold' means—whether it creates files on disk or merely returns content—and does not address the openWorldHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences. It front-loads the primary action, then details the return value and parameters, and closes with context. Every sentence earns its place without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, return value, key parameters, and usage context, which is reasonably complete for a tool with six parameters and no output schema. Minor gaps remain, such as explaining the scaffold behavior and idempotency, but these are partially covered by annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 echoes the parameter names (access, extends, includes, bodyContent) but does not add deeper meaning beyond what the schema already documents, such as the PascalCase pattern or enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: generating an Aura Application bundle scaffold and returning the .app file content. It distinguishes this from sibling tools like sf_create_aura_component and sf_create_aura_event by focusing specifically on the app-level bundle and the /c/AppName.app URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that Aura Apps are standalone Lightning applications accessible via a URL, which helps infer when to use this tool. However, it does not explicitly mention alternatives or exclusions, such as when to prefer sf_create_lightning_app or LWC-based approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds the context of updating via Metadata API, but does not disclose important behavioral details such as whether unspecified fields are preserved or reset, or potential broader side effects of a metadata deployment. It does not contradict annotations, but adds only modest value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: the first explains what it does, the second enumerates configurable options, and the third gives the practical use case. Every sentence is informative and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 output schema, the description covers the main aspects: what it updates, what can be configured, and why to use it. It lacks explicit mention of permission requirements or whether the update is partial versus full replacement, but the overall context is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The tool description adds helpful interpretation for refreshTokenPolicy ('infinite, specific duration, or expire on password change'), which clarifies the enum values. However, it does not elaborate on session timeout format or IP relaxation semantics beyond the schema's terse descriptions, so the added value is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Updates the OAuth policies on an existing Connected App in Salesforce via the Metadata API,' specifying a distinct verb and resource. It lists the configurable aspects (refresh token policy, single logout URL, session timeout, IP relaxation) and distinguishes itself from sibling tools like sf_create_connected_app by emphasizing 'existing' Connected Apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use this to tighten or adjust security policies on deployed Connected Apps.' This implies it is for modifying existing apps post-deployment, but it does not explicitly exclude alternatives or state when not to use the tool. The context is clear enough for an agent to select this over creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the upsert behavior ('Creates or updates') and notes that labels support translation, which is mildly informative. However, it doesn't disclose important behavioral details like name conflict resolution, permission requirements, or the fact that updates are based on fullName. Given the annotations already indicate idempotent write behavior, this is acceptable but not rich in additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, well-structured three sentences. It leads with the core action (create/update), then provides background on what Custom Labels are, and concludes with clear use cases. Every sentence adds value without redundancy or filler, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple upsert tool with six parameters and full schema coverage, the description provides sufficient context to understand its purpose and typical usage. It lacks explicit mention of how updates are triggered (e.g., by fullName) or potential side effects, but the annotations cover the safety profile. Overall, it is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all six parameters (100% coverage), so the description adds little beyond the schema. It mentions translation support, which implicitly relates to the 'language' parameter, but doesn't elaborate on any specific parameter semantics. Thus the description does not significantly enhance understanding beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates or updates a Salesforce Custom Label' with a specific verb and resource. It further explains what Custom Labels are and provides concrete use cases ('internationalizable text strings, error messages, or UI labels'), distinguishing it from sibling tools like sf_create_custom_field or sf_create_custom_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 for internationalizable text strings, error messages, or UI labels'), providing clear context for appropriate usage. However, it doesn't mention alternatives or exclusions, such as using sf_translate_custom_label for translation tasks, which would have strengthened the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnlyHint and idempotentHint. The description adds that Metadata Types store 'configuration data that can be packaged and deployed,' which is useful context. However, it does not disclose behavior on conflicts, whether repeated calls are safe, or any side effects beyond creation, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise two-sentence structure: the first states the action and key naming detail, the second explains purpose and usage context. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides adequate conceptual context (metadata vs. custom objects, packaging/deployability) and the schema covers all parameter details. It is complete enough for an agent to understand when and why to use the tool, though it could be slightly richer regarding edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents each parameter. The description mentions 'optional custom fields' which aligns with the schema but adds no extra semantic detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates') and resource ('Custom Metadata Type') with a clear naming convention (ending in __mdt). It also distinguishes from siblings by contrasting with custom objects, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage context: 'Use when a user wants to store configuration in metadata rather than custom objects.' This clearly indicates when to use the tool, though it does not name alternative sibling tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds useful behavioral detail: the created type appears in the notification bell, supports mobile push, and is triggered via Flows/Apex/Process Builder. This helps the agent understand the tool's effect and its integration points, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, and each sentence adds useful context without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (all parameters described), helpful annotations, and the description's integration context, the tool is well-documented. No output schema exists, but the description does not need to explain return values for a simple create operation; it covers the main behavioral and usage aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter descriptions, so the baseline is 3. The description does not add significant semantic detail about parameters like fullName or customNotifTypeName; it only relates mobile push to the mobile behavior. Schema already covers parameter meaning adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: creating a Custom Notification Type usable in Flows, Apex, or Process Builder. It includes specific context about where notifications appear (bell/mobile push), distinguishing it from a generic creation tool. However, it does not explicitly differentiate from the sibling tool sf_create_notification_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use context: 'Use to create in-app alerts for important business events.' It also states the notification type can be sent via Send Custom Notification action, giving the agent a clear scenario. It does not mention exclusions or alternatives, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining that Custom Settings are accessible via Apex without SOQL queries and that Hierarchy type supports overrides. It aligns with annotations (readOnlyHint=false, idempotentHint=true) and does not contradict them. It could mention permissions or idempotency impacts, but the annotations already cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the action ('Creates a Custom Setting object'). Four sentences deliver essential context without redundancy. Every sentence adds value, covering use cases and type behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema richness (100% coverage) and annotations, the description provides sufficient context for a creation tool: what it creates, when to use it, and key type behaviors. It does not explain the return value or error cases, but with no output schema, that is a minor gap. The description is fairly complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add specific parameter-level details beyond what the schema already provides (e.g., 'ending in __c' mirrors fullName pattern, 'Hierarchy or List type' mirrors settingType enum). It adds high-level context but does not strongly enhance schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Custom Setting object with Hierarchy or List type, and explains the resource ('Custom Setting object ending in __c'). It also provides context about purpose, but it does not explicitly differentiate from similar tools like sf_create_custom_metadata_type or sf_create_custom_object, though the terminology 'Custom Setting' is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use it: 'Use for feature flags, thresholds, or configurable constants.' It also explains the behavior of hierarchy types. However, it does not mention alternatives or when not to use this tool, so it falls short of explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, covering the basic write behavior. The description adds the contextual insight that PRs are code review requests, but does not disclose additional side effects, prerequisites (e.g., work item existence), or response behavior beyond what annotations and schema imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose. The parameter list is clear and direct, with no redundant text. Every sentence serves a purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with three parameters, the description sufficiently explains the operation and parameter roles. No output schema exists, so return value information is not provided, but this is a minor gap. The combination of annotations, schema, and description covers the essential context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, and the description repeats the parameter names with one-line meanings. This adds little beyond the schema but does reinforce the core parameters. The baseline of 3 is appropriate since the schema carries the full semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Creates a pull request record for a DevOps Center work item.' This clearly distinguishes it from sibling DevOps tools like promote or commit, and the additional context about code review requests reinforces its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that pull requests are for code review before merging, implying this tool is used at that stage of the DevOps workflow. However, it does not explicitly name alternatives or state when not to use it, though the context is strong enough to guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds prerequisites and the behavior of the rule itself, but doesn't disclose tool-specific behavior such as idempotency (despite idempotentHint=true) or what happens if the rule already exists. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding value: creation purpose, action modes, supported objects, and prerequisite. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with full schema coverage and no output schema, the description adequately covers the main purpose, dependencies, and rule behavior. It could additionally mention success/error responses, but that is not required given the schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already fully documented. The description adds thematic context (e.g., actionOnInsert/actionOnUpdate map to block/warn/silent) and mentions the required matching rules, but doesn't elaborate on individual parameter syntax or edge cases beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Creates a Duplicate Rule' and explains its purpose (detect potential duplicates using Matching Rules). It also lists supported objects and the three action modes (block, warn, silent), which distinguishes it from sibling creation tools like sf_create_matching_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by stating that existing Matching Rules are required, implying the user must create those first. However, it doesn't explicitly name alternative tools or state when not to use this tool, so it's not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds minimal behavioral context beyond the tool's function, such as not stating permissions needed or side effects. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the primary action and include essential context. Every sentence earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 9 well-documented parameters and no output schema, the description gives a clear purpose and usage context. It could mention prerequisites or post-creation effects, but the schema and annotations fill most gaps. The context is sufficient for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of all 9 parameters with descriptions. The description redundantly mentions 'email template' and 'recipients (owner, creator, users, roles, or custom email addresses)' which partially maps to parameters but does not add new meaning beyond the schema's own documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a Workflow Email Alert action' with a specific verb and resource. It also clarifies that it can be triggered by Flows, Approval Processes, or Workflow Rules, distinguishing it from other create tools like sf_create_workflow_rule or sf_create_email_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use when you need to send notification emails as part of automation' gives clear context for when to use this tool. It does not explicitly name alternative tools or list exclusions, but the automation-focused wording helps differentiate from direct email sending tools like sf_send_email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true) already convey the operation is a non-destructive write. The description adds context about external objects' capabilities (lookups, related lists, reports) but does not disclose behaviors such as what happens if the external data source is invalid, whether creation overwrites an existing object with the same name, or any permission prerequisites. This is sufficient given annotations 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and every sentence adds value: what it creates, what external objects are, and a prerequisite. No redundant or verbose content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with a rich schema and no output schema, the description explains the core concept, naming convention, and prerequisite. It does not detail the optional 'fields' array or externalName behavior, but the schema covers these. The description is complete enough for an agent to select and invoke the tool correctly, with only minor gaps around return values and field semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a clear description. The description reinforces the requirement for an existing external data source and the __x naming convention, but it does not add significant new meaning beyond the schema's pattern and descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Creates an External Object (ending in __x) linked to an External Data Source,' using a specific verb and resource. It distinguishes this from regular object creation (sf_create_custom_object) by clarifying external objects hold data in an external system and from sf_create_external_data_source, which creates the source itself. The naming convention and relationship to data sources make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to create an external object and already have an external data source, explicitly stating 'Requires an existing External Data Source.' It differentiates external objects from regular Salesforce objects by explaining their characteristics. However, it does not explicitly name alternative tools or provide exclusion criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and idempotency (idempotentHint=true). The description adds useful runtime behavior ('only the relevant dependent field values appear') and an example, but does not disclose potential edge cases like field validation, overwriting existing dependencies, or deployment implications. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and includes a concrete example that enhances understanding without unnecessary verbosity. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and full parameter schema coverage, the description provides sufficient conceptual context through the example and the explanation of runtime behavior. It lacks some edge-case details, but the existing annotations and schema fill most gaps, making it largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameter descriptions, so the baseline is 3. The description reinforces the relationship between controlling and dependent fields but does not add additional details beyond what the schema already offers, such as syntax or format specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Creates a field dependency between a controlling picklist and a dependent picklist on the same object.' It uses a specific verb ('Creates') and resource ('field dependency'), and includes an illustrative example that distinguishes it from sibling tools like creating custom fields or picklist values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'on the same object' and giving a concrete example, making it clear when this tool should be used. However, it does not explicitly mention when not to use it or name alternative tools for comparison, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that it sets FLS across profiles, but does not disclose additional behavioral traits like effects on existing FLS or required permissions. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a compact parameter legend. It front-loads the primary action and use case, with no redundant filler or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward setter tool with three fully documented parameters, the description covers what the tool does, when to use it, and how the parameters map to its operation. It does not explain return values or failure modes, but the annotations (idempotent, non-destructive) and openWorldHint provide enough additional context to make it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents objectName, fieldName, and profiles. The description repeats these in a compact legend and adds a concrete example for fieldName ('Revenue__c') and the profile object shape, but this adds only marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Sets') and resource ('field-level security for a field across one or more profiles'), and specifies the behavior (controlling read/edit per profile). This distinguishes it from siblings like sf_get_field_permissions (which reads permissions) and sf_create_permission_set (which creates a permission set).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Use after creating a custom field to make it visible and editable to the right profiles.' It does not mention alternatives or exclusions, but the scenario is clear enough for an agent to understand when to invoke this tool over similar permission-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the write nature is clear. The description adds context that list views appear in the object's selector and serve as shared filters, but it doesn't disclose permissions, side effects, or creation behavior beyond what annotations convey. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and each sentence adds value: the first states what it does, the second explains the concept and use cases. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and nested objects, the description provides a solid high-level orientation and purpose. It does not detail configuration steps, but the schema thoroughly documents all parameters. The mention of 'sorting' is slightly inaccurate since no sort parameter exists, but the overall context is sufficient for a create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and every parameter has a clear description in the schema (e.g., objectName, fullName, filters). The description adds a high-level mention of columns/filters/sorting but does not explain individual parameters beyond schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Creates a List View for any Salesforce object' with a specific verb and resource. It explains what list views are and gives concrete examples ('My Open Cases', 'High Priority Leads'), distinguishing it from other create tools in the sibling list like sf_create_custom_object or sf_create_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool ('Use to create shared views...') with practical examples. However, it does not explicitly mention when not to use it or alternatives, so it misses the exclusion part for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly=false and destructive=false, so the description doesn't need to restate mutation. It adds context about the creation dependency, but does not disclose permission requirements, error conditions, or what happens on duplicate rule creation attempts. Given the annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, all purposeful, front-loaded with the primary function, and includes the key usage prerequisite. No wasted words or redundant restatement of the tool title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with a fully documented schema and annotations, the description covers what the tool does, how to use it (fields and algorithms), and its prerequisite relationship to Duplicate Rules. It does not explain return values, but no output schema exists and this is typical for creation tools. The absence of permission/error details is compensated by the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the parameter semantics are already fully documented. The description adds a helpful list of matching algorithms (Exact, FirstName, etc.) that maps to the matchingMethod enum, but does not introduce new meaning for other parameters like blankValueBehavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Matching Rule used by Duplicate Rules to detect duplicate records, with a specific verb ('Creates') and resource ('Matching Rule'). It distinguishes itself from sibling tools like sf_create_duplicate_rule by explicitly naming the dependency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: it must be created before a Duplicate Rule that references it, which is a useful ordering constraint. It does not explicitly name exclusions or alternatives, but the prerequisite note gives actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds context that these sets 'remove specific permissions' and are used for exceptions, but does not discuss side effects such as duplicate handling, deploy requirements, or permission prerequisites. With annotations covering the safety profile, the description provides moderate added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs: a clear purpose statement and a compact parameter list. It is front-loaded with the main idea and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation, the description explains the purpose and parameters. It lacks return value information, but no output schema exists and sibling tools suggest this is a metadata creation tool. Annotations provide idempotency and safety context, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, and the description repeats the parameter names and meanings. It adds no new information 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Creates a Muting Permission Set that removes specific permissions from users in a Permission Set Group.' This is a specific verb+resource and functionally distinguishes it from sibling 'sf_create_permission_set' and 'sf_create_permission_set_group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to create exceptions — e.g., a Permission Set Group grants broad access, and a Muting Permission Set removes a subset of that access for specific users.' This provides clear context for when to use, but does not name alternative tools or explicitly state when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly=false, destructive=false, and idempotent=true. The description adds context about page layout purpose and configuration (sections, related lists), but does not detail side effects like overwriting existing layouts, permission requirements, or assignment behavior beyond creation. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, and every sentence adds value: defining what it creates, explaining the domain concept, and indicating how to structure the layout configuration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with full schema coverage and annotations, the description is sufficiently complete. It explains the purpose, key configuration elements, and relationship to profiles/record types. It lacks explicit output/return details, but no output schema exists and the operation is clearly a creation action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions 'sections with fields' and 'related lists', which aligns with schema parameters, but adds no extra semantic detail beyond what schema property descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a Page Layout for a Salesforce object' with a specific verb and resource, and distinguishes it from sibling tools like create_compact_layout or assign_layout_to_record_type by explaining what page layouts do (control fields, related lists, buttons).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 to define record detail/edit page composition for an object. It also notes that layouts are assigned to profiles and record types, hinting at context, but does not explicitly name alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutation (readOnlyHint=false) and idempotency. The description adds meaningful behavior beyond annotations by explaining Platform Events' pub/sub nature and clearly distinguishing PublishAfterCommit from PublishImmediately. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The first sentence states the core purpose, and the subsequent sentences add essential architectural and publish-behavior context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a rich schema and no output schema, the description covers the tool's purpose, naming constraint, and key behavioral options. It lacks explicit mention of failure modes or return values, but those are not critical for a create tool with this schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, including detailed explanations for fullName pattern and publishBehavior. The description mostly restates these concepts (__e suffix, publish behavior), adding little new parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately identifies the verb and resource: 'Creates a Platform Event object (ending in __e)'. It also distinguishes this from sibling tools like sf_create_platform_event_trigger by clarifying this is the event definition, not a trigger or custom object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context about event-driven architecture and publish/subscribe behavior, which implies when to use it. However, it does not explicitly state when not to use it or mention alternatives such as custom objects or the related platform event trigger tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond annotations, such as 'fires when a Platform Event message is received (after insert)' and example applications. However, it does not disclose potential side effects like overwriting an existing trigger, deployment requirements, or permission necessities. Annotations already indicate it is a write operation (readOnlyHint: false) and idempotent (idempotentHint: true), so the additional behavioral burden is only partially met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence states the purpose, the second provides use cases, and the parameter list is simple and scannable. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter creation tool with full schema coverage and annotations, the description is adequate. It covers the what, when, and parameter meanings. The main gap is the lack of information about post-creation behavior (e.g., whether the trigger is automatically active or needs deployment), which is not covered by annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already including examples and descriptions (e.g., eventApiName: 'Platform event API name, e.g. MyEvent__e'). The description repeats these parameter details without adding new semantics beyond the schema. No additional parameter-specific guidance is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Creates' and specifies a unique resource: 'an Apex trigger that fires when a Platform Event message is received (after insert)'. This distinguishes it from the generic sf_create_apex_trigger sibling and other create_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: 'Use to process incoming platform events with Apex logic' and gives concrete examples. It does not explicitly mention alternatives or exclusions, but the use cases provide clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-readOnly, non-destructive, non-idempotent behavior. The description adds useful context about what is created (Group SObject with Type=Regular) and member types, but does not disclose potential edge behaviors such as duplicate name handling, permission requirements, or side effects. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and purpose. Every clause contributes: creation, object type, use cases, member composition, and a pointer to the dependent sharing rule tool. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward create tool with no output schema, the description covers the essential context: what is created, why it is used, and what can be included. It lacks a mention of return value or failure modes, but given the simplicity and complete schema, this is a minor gap. It is sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for groupName, label, and members including member types. The description reinforces the meaning of members by stating that groups can include users, roles, and other groups, but adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Creates a Public Group (Group SObject with Type=Regular)' and lists specific use cases: 'for sharing rules, email distribution, or queue membership'. This specific verb-resource pair and technical detail (Type=Regular) distinguishes it from sibling tools like sf_create_queue or sf_create_role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use context by listing use cases and explicitly points to a related tool: 'Use as a sharing target in sf_create_sharing_rule.' However, it does not state when not to use this tool or compare with alternatives like sf_create_queue, so it misses explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and openWorldHint=true. The description adds domain context (queues are groups of users, records are worked on by any member) but does not disclose additional behavioral traits such as permissions, side effects, or metadata deployment specifics. This is adequate given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the action, and every sentence adds value: what it does, what queues are, how they work, and when to use them. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 params, nested objects) and strong schema/annotation coverage, the description is largely complete. It explains the purpose and typical use cases, though it omits details about return values or prerequisites (e.g., needing to create users first). These are minor gaps given the clarity of the core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific details but its explanation of queue concepts (e.g., records, groups) provides indirect context for understanding parameters like supportedObjects and queueMembers. No additional semantic value is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a Queue in Salesforce' with a specific verb and resource, and explains the purpose of queues. It distinguishes this from sibling tools by focusing on queue creation, and the context about record assignment helps clarify the tool's unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear use cases: 'Use for support teams, sales teams, or any scenario where multiple people share a pool of records to process.' It does not explicitly mention when not to use or name alternatives like sf_assign_queue_member, but the context is sufficiently clear for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations. It mentions 'via the Metadata API' which hints at deployment, but does not disclose side effects, permission requirements, or return behavior. Annotations already indicate mutation and idempotency, so the description does not contradict but adds little extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences, front-loaded with purpose, and no wasted words. It efficiently covers purpose, supported types, and optional parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 7 parameters and no output schema, the description covers the essential purpose, supported types, and optional parameters. Annotations cover safety traits. It does not mention return values or error conditions, but that is not critical with no schema present. The description is adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents all parameters. The description adds a small hint that targetObject is for Create type and fields are for the layout, but the schema already states these (e.g., targetObject is 'required for Create type'). Thus the description provides little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an object-specific quick action via the Metadata API and lists the supported action types. This distinguishes it from the sibling sf_create_global_action, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for object-specific quick actions and supports specific action types (Create, Update, LogACall, SendEmail). While it doesn't explicitly name alternatives like sf_create_global_action, the 'object-specific' qualifier implies when to use this tool versus global actions, and the type list implies limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the operation is a write, non-destructive, and idempotent. The description adds explanatory context about record types but does not disclose additional behavioral traits such as handling of existing record types or permission requirements. With good annotation coverage, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: function, concept, and concrete example. No filler or repetition; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 7 well-documented parameters and informative annotations, the description is adequate. It lacks an explicit explanation of the businessProcess parameter's applicability but the schema covers it. No output schema exists, so return value explanation is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, including examples for fullName and objectName. The tool description itself does not add parameter semantics beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Creates a Record Type on a Salesforce object' and provides an example with 'Enterprise' and 'SMB' record types on Opportunity, which distinguishes it from broader record creation tools (sf_create_record) and layout assignment tools (sf_assign_layout_to_record_type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the purpose of record types in enabling different layouts/picklists/processes, implying it should be used when such differentiation is needed. However, it does not explicitly list alternatives or exclusions, so the guidance is contextual rather than prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) already disclose the safety profile. The description adds context about report type structure and relationships, which is helpful, but it does not elaborate on deployment details, permissions, or side effects. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) with the verb and resource upfront. Every sentence contributes meaningful information—definition, structural explanation, and usage guidance—without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool without an output schema, the description provides sufficient conceptual grounding: what a report type is, its key components, and when to use it. It doesn't cover every edge case, but the schema fills in parameter details, making the overall description adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has descriptive text. The description adds minimal semantic value beyond mentioning primary object and relationships, which aligns with baseObject and relationships parameters. A baseline 3 is appropriate since the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Creates a Custom Report Type' and explains its purpose—defining available objects and fields for reporting. It further distinguishes it by detailing primary/related objects, differentiating it from sibling report creation tools like sf_create_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates when to use the tool ('Use when the standard report types don't include the data you need...'). It provides clear context but does not mention when-not to use it or name alternative sibling tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds useful conceptual detail on how sharing rules operate (automatic sharing based on criteria or ownership) but does not disclose implementation-side behaviors such as permission requirements or what happens on duplicate rule names. It complements annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, then concise context. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema fully documents parameters (8 params, nested objects, enums), the description provides essential conceptual backing and usage context. It does not explain return values, but no output schema exists and creation tools typically confirm success. Slight gap: lacks prerequisite details like object-level permissions, but overall sufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema carries detailed parameter info. The description enhances understanding of ruleType by explaining criteria-based vs ownership-based sharing, and clarifies sharedTo semantics. However, it doesn't add meaning to most other parameters beyond what schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Creates a Sharing Rule for a Salesforce object.' It clearly distinguishes from other creation tools by explaining the underlying concept (extending OWD) and the two types (criteria-based, ownership-based). No tautology, accurately reflects 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case: 'Use to give specific roles/groups access to records they wouldn't normally see based on OWD.' However, it does not explicitly mention alternatives like permission sets or when not to use sharing rules, though the context implies it's for OWD-driven sharing needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the baseline safety profile is known. The description adds the ETM enablement prerequisite, but does not disclose other behavioral details such as failure modes or uniqueness constraints. This is comparable to the calibration example that earned a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one opening sentence, a prerequisite, and a focused parameter list. No redundant or fluff content. Key information is front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, the description covers the essential prerequisite, purpose, and the most complex parameters (territoryType, parentTerritoryName). The remaining access-level parameters are sufficiently documented in the schema, so the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description reiterates several parameters (e.g., territoryName as API name) and gives examples for territoryType, but does not add significant new meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates a Territory') and the specific domain ('Enterprise Territory Management (ETM)'), which distinguishes it from sibling tools like sf_create_service_territory. It also adds domain context by explaining that territories define logical sales regions or account groupings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite ('Requires ETM to be enabled in the org') and context on what territories are used for, giving the model an indication of when to use this tool. It does not explicitly list exclusions or alternative tools, but the ETM qualifier provides sufficient differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the key constraint that markup must include an <apex:component> tag, but does not disclose what happens if the component already exists, permission needs, or deployment effects—information that would improve transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the core purpose and method, the second covers the required input and usage pattern. Every sentence earns its place, making this a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation, the description is nearly complete: it covers what is created, the API used, required content constraints, and how the result is used. It lacks explicit conflict behavior and prerequisites, but the annotations compensate slightly, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 maps the required params (componentName, label, content) to natural-language terms but does not elaborate on apiVersion or description, which are already self-explanatory in the schema. It adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Creates') and identifies the exact resource ('reusable Visualforce component (ApexComponent)') via the Metadata API. It clearly distinguishes from sibling tools like sf_create_visualforce_page by emphasizing reusability and inclusion syntax, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by explaining that components can be included in Visualforce pages, which indicates the use case for reusable UI fragments. However, it does not explicitly compare with alternatives or state when not to use this tool, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, and the description aligns with these. It adds limited behavioral context such as optional filtering and a default limit, but it does not describe return format, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the purpose, the second gives usage guidance, and the param list is compact. It contains no unnecessary prose and is well structured for quick agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with optional filters and a default limit, the description covers the essential invocation details. It does not mention return fields or pagination, but the lack of an output schema makes that less critical, and the annotations cover the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description repeats the parameter names and their roles without adding new semantic detail. It confirms projectId and stageId are filters and limit is a maximum, but these are already present in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Lists DevOps Center work items.' It also clarifies optional filters by project or pipeline stage, distinguishing it from sibling tools like sf_list_devops_projects, which target a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context with 'Use to get an overview of work in progress.' However, it does not explicitly mention when not to use the tool or name alternatives, though no direct sibling alternative for listing work items exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: it notes that 'Existing translations for the same label and language will be overwritten,' which aligns with the idempotentHint, and mentions the prerequisite. This adds context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose, and contains no redundant or irrelevant information. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter upsert tool with annotations, the description covers purpose, operation, prerequisites, and side effects (overwrite behavior). It does not explain failure cases or return values, but those are not critical given the tool's simplicity and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all three parameters, including examples. The description repeats some of this information (e.g., language codes) but adds no additional meaning beyond what the schema already states, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Adds or updates a translation for a Salesforce Custom Label via the Metadata API (Translations type).' This uses specific verbs and identifies the resource (Custom Label), distinguishing it from sibling tools like sf_create_custom_label and sf_translate_field_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the operation and prerequisites (Translation Workbench must be enabled), but it does not explicitly compare with alternatives (e.g., sf_translate_field_label) or state when not to use this tool. Guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and readOnly=false, covering mutation and idempotency. The description adds useful context about the Metadata API and the Translation Workbench prerequisite. However, it does not disclose potential side effects (e.g., deployment time, need for specific permissions) beyond what annotations imply, so it adds moderate value without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the main action. Every sentence provides essential information: what it does, required inputs, optional input, and a prerequisite. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description is largely complete. It covers the operation, all required and optional inputs, and a key dependency. It does not describe the response format or error behavior, but these are less critical given the tool's simplicity and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented. The description reinforces the meaning of each parameter (e.g., object API name, field API name, language code) and provides examples like 'fr', 'de', 'es'. It adds minimal additional semantics beyond the schema, earning a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Adds or updates a translation for a field label (and optionally help text) on a Salesforce object via the Metadata API (CustomObjectTranslation type).' It provides a specific verb, resource, and API type, distinguishing it from related tools like sf_translate_custom_label and sf_create_custom_field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by specifying the required inputs and the prerequisite that 'Translation Workbench must be enabled.' It does not explicitly name alternative tools for exclusion, but the sibling tool sf_translate_custom_label exists, and the focus on 'field label' implies the differentiation. A more explicit contrast would elevate this to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, idempotentHint=true), the description discloses the critical placeholder behavior for omitted files, which is a significant side effect not obvious from the schema. It also mentions redeployment via Metadata API, adding context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose. The critical warning is placed in the second sentence, and no filler. Excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives key usage warning and deployment method, but the contradiction with schema leaves uncertainty about the actual behavior of omitted files. It also doesn't address what happens after update (e.g., deployment status) or prerequisites, though output schema is absent. Major completeness gap from contradiction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all parameters (100%), including 'leave undefined to keep existing' for css/html/javascript. The description's warning that omitted files use 'empty placeholders' directly contradicts the schema's 'leave undefined to keep existing,' creating confusion about whether omitting preserves or wipes. This contradiction undermines parameter clarity, so below baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates an existing Lightning Web Component by redeploying it with updated HTML, JavaScript, or CSS,' specifying the action, resource, and method. This distinguishes it from sibling tools like sf_create_lwc, which creates new components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on file handling: 'Provide only the files you want to update — any files omitted will use empty placeholders (so you should provide all files you want to keep).' This tells the agent how to invoke correctly. However, it doesn't explicitly name alternative tools or when not to use, only implying 'existing' components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, idempotent, non-destructive write. The description adds the key matching semantics—'If a record with the given external ID value exists, it is updated; otherwise a new record is created.' This goes beyond annotations but omits edge cases like duplicate external IDs 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—a one-sentence overview followed by a short parameter list with examples. It front-loads the primary behavior and avoids unnecessary detail, though the parameter list overlaps with schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core upsert logic and parameter meanings, but it fails to mention return values (no output schema), error conditions (e.g., non-unique external ID), or preconditions such as required permissions. These gaps make it insufficient for an agent to fully anticipate tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are described in the schema (100% coverage). The description repeats these with minor example additions (e.g., 'Account', 'Legacy_Id__c'), but this doesn't materially enhance understanding beyond the schema, so it earns the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Creates or updates a Salesforce record using an External ID field for matching,' which is a clear verb+resource+mechanism. It also explains the create-or-update logic, distinguishing it from sibling tools like sf_create_record and sf_update_record by the external ID matching behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for scenarios where you want to upsert based on an external ID, but it does not explicitly mention alternatives or conditions to avoid using it. The context is clear but lacks explicit exclusions, scoring a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing the two-step behavior: 'Creates a ServiceResource for the user if one does not already exist, then creates a ServiceResourceSkill record.' It also clarifies the representation of ServiceResource. Given the annotations (readOnlyHint=false, idempotentHint=true) already indicate mutation and idempotency, this additional detail provides valuable behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence summary, a bulleted parameter list, and a brief explanatory note on ServiceResource. It is front-loaded with the core action and avoids unnecessary fluff. Slightly redundant in repeating schema info, but remains efficient, so a 4 is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 3 parameters and no output schema, the description covers the main behavior, the data model (ServiceResource/ServiceResourceSkill), and parameter specifics. It does not detail return values or permissions, but given the simplicity and existing annotations, the description is sufficiently complete to guide an agent, earning a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. However, the description adds meaning by specifying skillName as 'the API name (DeveloperName)', clarifying username as 'Salesforce username (e.g. agent@example.com) or user ID' (which is not in the schema), and reiterating skillLevel with range. These enrichments go beyond the schema's basic descriptions, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Assigns a Skill to a Salesforce user (service agent) with a skill level rating.' It specifies the resource (Skill, user/service agent) and the additional behavior of creating ServiceResource and ServiceResourceSkill records. This distinguishes it from siblings like sf_create_skill or sf_assign_presence_status, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context by mentioning 'Field Service / OmniChannel' and the creation of a ServiceResource, implying it is for service agents in those contexts. However, it does not explicitly state when to use this tool over alternatives, nor does it list exclusions or prerequisites. The usage guidance is implied rather than explicit, meriting a middle score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutating behavior (readOnlyHint=false, idempotentHint=false) and non-destructive nature. The description adds valuable context: asynchronous execution, returns a job ID for status tracking, and upsert behavior when externalIdField is provided. This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The parameter list duplicates schema information but is brief and does not detract significantly. Slightly redundant, but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the method, efficiency trade-off, async behavior, and job ID return. It does not explain tracking mechanics or error handling, but no output schema is expected. Given the moderate complexity and available annotations, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description repeats parameter names and adds brief clarifications (e.g., externalIdField 'performs upsert instead of insert'), but this largely mirrors the schema descriptions. No significant additional meaning is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inserts multiple records asynchronously via Bulk API 2.0. It specifies the resource (records of an object type) and method (bulk insert), distinguishing it from individual REST calls by noting efficiency for large volumes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates use for large volumes ('More efficient than individual REST calls for large volumes') and notes the async nature with job ID tracking. It does not explicitly name alternative tools or exclusion criteria, but the guidance is clear for typical bulk-load scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, idempotent operation. The description adds context about the Metadata API mechanism and configurable target behaviors (sidebar, new window, etc.), which goes beyond what annotations convey, though it does not describe deployment side effects or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core action and resource, and each sentence adds distinct supporting detail with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus the rich schema provide a good baseline, but it omits potentially important operational nuances such as whether the button must be manually added to a page layout and how deployment outcomes are reported. Given the tool's complexity and lack of an output schema, this leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 7 parameters with descriptions and enums, so the description adds little new semantic detail. It only loosely restates the meaning of contentSource and openType, aligning with the baseline expected when schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Creates') and a specific resource ('custom button or link on a Salesforce object via the Metadata API (WebLink)'), and it enumerates supported button types and content sources, making it clearly distinct from sibling creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool by listing supported button types (list, detail, mass action) and content sources (URL, JavaScript, Visualforce), but it does not explicitly mention alternatives or situations where another tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds value by explaining the purpose (classification and visibility controls) but does not disclose additional behavioral traits such as what happens on duplicate names, or permission requirements. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a clear purpose statement followed by a brief parameter summary. The parameter list partially duplicates the schema but is compact enough to serve as a quick reference, earning a 4 rather than a 5 for slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full schema coverage and annotations (idempotent, non-destructive), the description provides sufficient context for invoking the tool. It lacks details on return values or error handling, but for a metadata creation tool with rich structured metadata, this is acceptable and not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the description adds meaningful clarification by summarizing key parameters and emphasizing that 'categories' are top-level with optional sub-categories. This aids comprehension beyond the raw schema definitions, especially for the nested structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Creates a Data Category Group with categories for classifying Salesforce Knowledge articles, solutions, or cases.' It uses a specific verb ('Creates') and resource ('Data Category Group'), and the mention of hierarchical content classification distinguishes it from other metadata creation tools among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Data categories enable hierarchical content classification and visibility controls.' This implies its use for Salesforce Knowledge classification scenarios. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and idempotency (idempotentHint=true), and the description confirms the creation behavior without contradicting these. It adds value by explaining the action sets a field and can be standalone or associated, which is not in the annotations. No major side effects are disclosed, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, with the main purpose in the first sentence and a parameter list that repeats schema but is readable. It is front-loaded and does not contain filler. The parameter list is somewhat redundant, but the overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, no output schema), the description adequately covers the core creation behavior, the operation types, and the optional association with rules/approvals. It doesn't mention prerequisites or return values, but these are not required given the schema and annotations. It feels complete enough for a create action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 lists each parameter with short explanations, but these largely mirror the schema descriptions (e.g., formula: 'Apex formula (for Formula operation)' vs schema's 'Formula expression (when operation=Formula)'). It adds minimal new semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Creates a standalone Workflow Field Update action' with specific behavior: sets a field to formula, literal, or null. It distinguishes the tool from siblings like sf_create_workflow_rule by focusing on the field update object itself and its standalone or associable nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the tool can be used with Workflow Rules, Approval Process steps, or independently, giving clear usage context. It does not explicitly name alternative tools, but the scope is evident. No exclusions are mentioned, but the context is sufficient for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a write operation (readOnlyHint=false) and idempotent. The description adds domain context about the letterhead structure (colors) but does not disclose behaviors like duplicate handling or permissions. It also mentions 'footer colors' though no footerColor parameter exists, which is a minor inaccuracy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized in two paragraphs: purpose first, then parameters. The parameter list is somewhat redundant with the schema but remains compact and readable. No irrelevant information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward creation tool with full schema coverage and annotations, the description is sufficient. It explains the artifact and its purpose without needing to describe output details. Minor missing context about potential side effects is covered partly by the idempotency annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying the roles of backgroundColor vs bodyColor vs headerColor, which the schema's short descriptions only partially convey. However, much of the parameter list paraphrases the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action 'Creates a Letterhead' and identifies the resource. It further explains the letterhead's purpose as a visual wrapper for HTML email templates, clearly distinguishing it from sibling tools like email template creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by explaining that letterheads can be referenced by email templates for brand consistency. It does not explicitly name alternatives or state when not to use it, but the context is clear and useful for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds behavior beyond that: it returns generated code for review, not a deployment. This clarifies that no org modification occurs, which is useful context not fully captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: two sentences stating purpose and workflow, followed by a compact parameter list. It avoids fluff, but the parameter list is somewhat redundant with the schema, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description tells the agent the return type (generated code scaffold for HTML, JS, CSS, meta XML) and that it's for review before deployment. This is sufficient for a non-mutating generation tool, though a bit more detail on return format would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description's parameter list largely restates the schema (e.g., 'componentName: LWC component name in camelCase'). It adds minimal meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a complete LWC component scaffold (HTML, JS, CSS, meta XML) from plain-English requirements. This specific verb+resource+output combination distinguishes it from sibling tools like sf_create_lwc or sf_guide_lwc_accessibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the generated code is for review before deploying with sf_create_lwc, which gives a clear workflow context. It implies use when you have requirements descriptions, but does not explicitly state when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, idempotent, and non-destructive behavior. The description adds useful context beyond annotations by specifying the created files (package.json, tsconfig.json, src/index.ts, etc.) and the subsequent build commands. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each adding a distinct piece of information: purpose, file list, SDK context, input requirement, and post-generation steps. It is front-loaded with the purpose and avoids unnecessary fluff, though slightly longer than the minimal ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives sufficient context for an agent to invoke the tool and follow up: what it creates, the key input, and next steps. No output schema is expected, and the description covers the tool's behavior adequately. It doesn't mention that no org connection is made, but that's not critical for a scaffolding operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all four parameters. The description's mention of outputDirectory as an absolute path only reiterates the schema. It adds no significant new parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generates a complete, working MCP server project structure on disk targeting a Salesforce org' with a specific verb and resource. It lists concrete files generated, making it distinct from siblings like sf_create_mcp_tool which likely creates a tool rather than the server scaffold.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: instructs the agent to 'Provide an outputDirectory (absolute path)' and gives post-generation steps ('run npm install' then 'npm run build'). It lacks explicit exclusions or alternatives, but the uniqueness of the tool makes the usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is a write operation (readOnlyHint=false) and may have side effects (openWorldHint=true). The description adds valuable context by specifying that the message 'sends a SOAP XML payload to an external endpoint' and is triggered by workflow rules, clarifying the asynchronous callout behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a two-sentence purpose statement followed by a compact parameter list. It front-loads the core functionality without extraneous content, though the parameter list duplicates schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters (5 required) and no output schema. The description covers the tool's purpose, trigger context, and all parameters. It lacks explicit mention of return values or permission prerequisites, but for a create-metadata tool of moderate complexity, the description is sufficiently complete for an agent to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 7 parameters with 100% coverage, each with a meaningful description. The description's parameter list adds marginal value by noting integrationUser is 'optional username to authenticate the callout,' but this is largely redundant with schema descriptions. Baseline 3 is appropriate since the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Creates a Workflow Outbound Message' with a specific purpose: 'sends a SOAP XML payload to an external endpoint when triggered by a Workflow Rule or Approval Process.' This distinguishes it from sibling tools like sf_create_workflow_rule or sf_create_email_alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use for real-time integration with external systems that need to be notified of record changes.' This gives the agent a condition for selection, though it does not explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the write nature is encoded. The description adds context about statusType semantics but does not disclose idempotency (despite idempotentHint=true), potential uniqueness constraints, or any side effects beyond creation. It provides some value but not rich behavioral detail beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main sentence, bullet points for statusType, and a note about serviceChannels. It is appropriately sized and readable, though the statusType bullets could be slightly more compact without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with no output schema, the description covers the purpose, parameter semantics, and a follow-up action. It doesn't explain return values or error conditions, but those are not critical given the context. It provides enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description compensates for the undocumented parameters. It thoroughly explains statusType (with meaning of each enum) and serviceChannels (which channels are active for Busy). However, label and statusName are not elaborated beyond the schema's minimal descriptions, leaving a slight gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a Presence Status that agents can set to indicate their availability,' which is a specific verb + resource. It distinguishes from sibling tools like sf_assign_presence_status (which assigns) and sf_create_presence_configuration (which is a different config object).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each statusType (Online, Busy, Offline) and that serviceChannels must be specified for Busy. It also explicitly suggests a next step: 'After creating, assign the status to profiles/permission sets with sf_assign_presence_status.' This gives clear usage context, though it doesn't explicitly exclude alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive write operation. The description adds domain context (Product2 in Quotes/Opportunities) and notes the default for isActive, which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a purpose sentence, usage hint, and parameter list. The parameter list duplicates schema but remains concise and readable without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core purpose, usage context, and parameter semantics for a tool with 6 parameters and 100% schema coverage. It omits error handling and prerequisites, but these are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond examples ('Hardware', 'Each') and marks a few parameters as optional. This is consistent with the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies 'Creates a Salesforce Product2 record' and explains the record's role in Opportunities and Quotes. This differentiates it from generic record creation tools and the related price book tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions using sf_create_price_book to set pricing, providing a clear companion-tool relationship. However, it does not describe when to avoid this tool or mention alternative creation methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and idempotency (idempotentHint=true). The description adds useful context by stating the page is 'deployed immediately and accessible at /apex/PageName' and that content must include an <apex:page> tag. It does not contradict annotations, but it does not reveal potential conflict behavior (e.g., what happens if the page already exists) or permissions needed, which keeps it just below a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the primary action, and every sentence adds value. It is concise without sacrificing key details, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no output schema), the description covers the core creation process and the three required inputs, but it does not explain the return value or success response. It also omits any mention of potential errors (e.g., duplicate page name) or permission requirements. The idempotency annotation partially covers re-running behavior, but a bit more context about what the tool returns would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter coverage with detailed descriptions for all 9 fields, so the description does not need to carry the burden. The description highlights the three required parameters and groups optional ones (controller, extensions, header/sidebar), but this mostly reiterates schema information. It adds slight value by clarifying that 'content' must include an <apex:page> tag, which the schema also states, so the added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates') and the specific resource ('Visualforce page'), and distinguishes it from sibling tools like sf_create_visualforce_component and sf_create_visualforce_email_template by the resource type. It also specifies the method ('via the Metadata API'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when creating a Visualforce page) and lists required and optional inputs. It does not explicitly mention alternatives or exclusions, but the context is clear enough that an agent can select it over related tools. There is no mention of when not to use it (e.g., for components or email templates), but that is inferable from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds that it returns work item details and merge conflict records, providing some output context. No side effects are described, but for a read-only check this is acceptable; the additional context earns a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a parameter line, with the main action immediately stated. No wasted words; every sentence contributes purpose, usage, or parameter semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, read-only, no output schema), the description covers what it does, when to use it, and what it returns. Annotations fill the safety gap. No additional detail is necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description 'DevOps Center work item ID' is identical to the schema's property description. The description repeats this without adding extra meaning (e.g., format, examples, or relationship to other tools), so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Checks' with a clear resource ('a DevOps Center work item for merge conflicts'). It clearly distinguishes from sibling tools like sf_resolve_devops_merge_conflict (detect vs. resolve) and is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use before promoting a work item to identify conflicts that need resolution.' This establishes timing and intent, though it does not explicitly name alternative tools for other scenarios like resolution or checkout.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent, open-world mutation. The description adds valuable context about how it mutates (via DebugLevel/TraceFlag), the prerequisite behavior for logging, and duration/verbosity semantics. No contradiction between description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a succinct purpose sentence, a parameter reference block, and a workflow sentence. It is appropriately sized and front-loaded with the core action. Some redundancy with the schema is acceptable but prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema, the description covers the effect, the required ordering with sibling tools, and practical usage. It omits details like permissions needed or behavior if a trace flag already exists, but overall is sufficient for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, including defaults, ranges, and enum values. The description's parameter list mostly repeats the schema, with slight elaboration like 'FINEST ... recommended for debugging' but adds no fundamentally new parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as enabling Apex debug logging for a user by creating a DebugLevel and TraceFlag via the Tooling API. It uses a specific verb and resource, and references sibling tools (sf_get_debug_logs, sf_get_debug_log_body), distinguishing it from log retrieval actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states this tool is required before sf_get_debug_logs will return anything new and provides a clear follow-up workflow: enable logging, perform the action, then call the sibling log tools. It does not explicitly list when-not-to-use scenarios, but the context strongly implies the intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds valuable context: uses the Tooling API, lists concrete anti-patterns detected, notes that test classes with __Test suffix are omitted, and includes class count limits. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: opening sentence states the purpose, second sentence lists what is detected, third provides usage guidance, and parameter details follow. Every sentence contributes value; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a scanning tool with 2 parameters, no output schema, and clear annotations, the description covers purpose, detections, use case, and parameter behavior. It omits what the output format looks like, which would be useful given no output schema, but it is otherwise complete for most agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters at 100%, providing a baseline of 3. The description adds a meaningful clarification by noting that classNames 'omits test classes with __Test suffix,' which is not present in the schema. This extra semantic detail raises the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as scanning Apex classes for common anti-patterns, listing specific examples (SOQL/DML in loops, hardcoded IDs, debug statements). However, it does not explicitly differentiate from similar siblings like sf_run_code_scanner, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage context: 'Use before deploying to catch performance and quality issues early.' This is helpful but does not mention alternatives or when not to use the tool, so it lacks the explicit exclusions/alternatives that would merit a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, idempotent, non-destructive operation. The description adds useful behavioral context by explaining the internal process ('Reads the existing FlexCard definition and redeploys it with isActive=true') and the outcome (visibility on Lightning pages and Experience Cloud). This goes beyond the basic annotation hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two short sentences that front-load the core purpose, followed by a clarifying mechanism and prerequisite. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the primary purpose, the effect, and a key prerequisite. Annotations provide safety and idempotency context. It could mention what happens if the card is already active, but the idempotentHint mitigates that gap. Overall, it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers the single parameter cardName with a clear description ('API name of the FlexCard to activate'). The description adds the prerequisite that the card must already exist, but this is more of a usage guideline than parameter semantics. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Activates an OmniStudio FlexCard') and the effect ('visible on Lightning pages and Experience Cloud sites'). It also explains the mechanism (reads existing definition and redeploys with isActive=true). This distinguishes it from sibling tools like sf_create_flexcard (creation) and sf_update_flexcard (modification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance: the card must already exist and be created with sf_create_flexcard, implying this tool is for subsequent activation rather than initial creation. However, it does not explicitly contrast with alternatives like sf_update_flexcard or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnly=false, destructive=false, and idempotentHint=true. The description adds a critical behavioral trait: 'without removing existing values', which directly addresses what is preserved (i.e., nothing existing is destroyed). This adds value beyond the annotations and clarifies the operation's non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action. The first sentence states the purpose and key constraint; the second provides the use case. Every word earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 parameters with rich schema descriptions and an open-world annotation. No output schema exists, but the description adequately covers the operation scope and expected outcome. It does not mention error handling or permissions, but for an additive, non-destructive operation this seems sufficient. Minor gap: no mention that adding a duplicate value might fail, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; all parameters (objectFieldFullName and values) have detailed descriptions in the schema, including the nested value properties (label, fullName, color, etc.). The tool description itself adds no extra parameter information, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Adds') and identifies the resource ('new picklist values to an existing Picklist or MultiselectPicklist field') with a key differentiator: 'without removing existing values'. This distinguishes it from potential update/replace operations and from sibling tools like sf_create_custom_field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use when a user wants to add new options to a dropdown.' It does not name alternatives (e.g., for replacing values) but the 'without removing existing values' clause clarifies it is not for editing. This is clear context, though not an explicit exclusion list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false), idempotent (idempotentHint=true), and non-destructive (destructiveHint=false). The description adds the useful behavioral note about agent selection, but doesn't disclose details like whether existing assignments are overwritten or appended, or whether it requires special permissions. With annotations covering the core safety profile, the description provides minimal additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and appropriately front-loaded. The first sentence states the core functionality, followed by a behavioral note and parameter clarifications. No redundant information is present, and the structure with line breaks for parameters makes it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose, the assignment prerequisite, and the parameter constraints. It doesn't describe the return value (but no output schema exists), nor does it mention required permissions or potential errors. There's a minor inconsistency between 'Profile names' in the description and 'Profile API names' in the schema, which could confuse. Overall, it's sufficient for correct invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters (100% coverage), so the baseline is 3. The description adds value by giving concrete examples for profiles, clarifying the format for permissionSets, and stating the 'either/or' requirement that is not enforced by the schema (which only requires statusName). This extra guidance helps avoid invalid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Grants access to a Presence Status for the specified Profiles and/or Permission Sets.' It uses a specific verb ('grants access') and resource ('Presence Status'), and the title further clarifies the target. This distinguishes it from sibling tools like sf_create_presence_status (which creates the status) and sf_assign_skill_to_agent (which assigns a different entity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical context: 'Agents can only select presence statuses that are assigned to their profile or permission set,' explaining why this assignment is necessary. It also specifies a precondition: 'Either profiles or permissionSets must be provided (or both).' However, it doesn't explicitly mention alternatives or situations where another tool would be more appropriate, so it lacks an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (write operation), idempotentHint=false, and destructiveHint=false. The description adds meaningful behavioral context beyond annotations: it is asynchronous, returns a job ID for status tracking, and requires each record to include the Salesforce Id. This helps the agent understand execution model and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a two-sentence purpose/behavior paragraph followed by parameter definitions. It avoids fluff and front-loads the most critical information (purpose, async nature, Id requirement, return type). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately explains the return value (a job ID). It covers purpose, parameters, and key constraints. It does not detail error handling or partial failure behavior, but for a bulk API tool with good annotations and schema, this is reasonably complete. Slight gap exists regarding how to track the job status, but that may be outside scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description's parameter lines mostly restate the schema but slightly enhance the records description by specifying 'plus fields to update', which is not explicit in the schema. This is a marginal addition, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: 'Updates multiple records of the same object type asynchronously using Salesforce Bulk API 2.0.' It clearly distinguishes from sibling tools like sf_update_record (singular) and sf_bulk_insert_records (insert) by emphasizing 'multiple' and 'Bulk API 2.0'. The key requirement of including the Salesforce Id field further clarifies the update semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for asynchronous bulk updates of multiple records, which implies usage when a single-record update is insufficient. However, it does not explicitly mention alternatives or when not to use it (e.g., vs. bulk import or bulk insert). The context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds useful context beyond annotations: it uses the Tooling API, applies a 75% deployment threshold, and implies it only reads existing test results (does not run tests). This additional behavioral context is meaningful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences cover purpose and usage, followed by a brief parameter breakdown. Every sentence adds value—no filler or repetition. It is well-structured and front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two optional parameters and no output schema, the description adequately covers purpose, usage, threshold, and parameters. It does not describe the exact return format, but given the lack of output schema and the simplicity, this is not a critical gap. It could mention limitations like pagination, but that's optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 restates the parameter meanings ('partial match', 'below this coverage percentage') nearly identically to the schema. It adds the word 'optional' but does not provide deeper semantics like format or behavior when parameters are omitted, which is already covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Retrieves Apex code coverage statistics from the org using the Tooling API' and specifies what it shows ('which classes meet or fail the 75% coverage threshold'). It distinguishes itself from sibling tools like sf_run_apex_tests and sf_get_apex_test_results by focusing on coverage statistics rather than test execution or results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use after running Apex tests to assess coverage.' This tells the agent when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, though the 'use after' phrasing implies it complements (not replaces) test-running tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context: what the response includes (statuses, component successes/failures, test results) and the 'recently completed' limitation, implying retention boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, front-loaded with the action and resource. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with no output schema, the description sufficiently explains the return payload, usage context, and relationship to sf_deploy_metadata. It is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the sole parameter deployId is well-described in the schema. The description reinforces the meaning but adds no additional semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Checks') and resource ('status of a metadata deployment') with the async job ID qualifier. It clearly distinguishes from siblings like sf_deploy_metadata (which performs the deployment) and sf_get_deployment_history (which lists past deployments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states explicit usage context with 'in-progress or recently completed deployment' and 'Use with the deploy ID returned from sf_deploy_metadata.' This gives clear when-to-use guidance, though it does not explicitly contrast with alternative status/history tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Retrieves' and 'Shows' align with these. It adds value by specifying that the tool returns recent commits and deployment outcomes, going slightly beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no filler. It front-loads the main action and result, and the parameter note is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and strong annotations, the description adequately explains the tool's purpose and output ('recent commits and their deployment outcomes'). It lacks detail on exact response format, but that is acceptable given the tool's simplicity and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'workItemId' already described as 'DevOps Center work item ID'. The description repeats this exact phrase without adding extra semantics, so it meets the baseline but does not enhance the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieves') and identifies the resource ('commit and deployment status for a DevOps Center work item'). It clearly distinguishes this from sibling tools like sf_commit_devops_work_item or sf_checkout_devops_work_item by focusing on status retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: to check commit and deployment status for a work item, clarifying it shows recent commits and outcomes. It does not explicitly name alternatives or exclusions, but the context is clear among the DevOps Center sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation and idempotency. The description adds meaningful behavioral context: CDC publishes change events to /data/ChangeEvents for create, update, delete, and undelete operations, and the tool works via the Metadata API. It does not discuss permissions or deployment side effects, but the added information goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. The main action is front-loaded, and every sentence provides distinct, relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter enablement tool, the description covers purpose, mechanism, input format, and supported object types. It lacks explicit return/verification behavior and prerequisites, but these are not critical given the simple interface and available annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single array parameter with examples, so the baseline is 3. The description reinforces that the array contains object API names and adds useful semantic context by stating standard and custom objects are supported, exceeding the schema's coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enables Change Data Capture for specified Salesforce objects via the Metadata API, naming the verb, resource, and mechanism. It also mentions the resulting change events channel, distinguishing it from sibling metadata tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical instruction to provide an array of object API names and notes that standard and custom objects are supported. However, it does not explicitly contrast this tool with alternatives or state when not to use it, leaving usage guidance mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical behavioral trait: classes used as Agentforce actions must have an @InvocableMethod, otherwise they 'will silently fail at runtime.' It also specifies that deployment is via the Metadata API, adding context beyond annotations. Annotations already indicate idempotency, and there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence earns its place: purpose, use cases, a critical IMPORTANT warning, and an example. It is well-structured with a clear flag and code block, making it easy to scan. Slightly verbose but justified by the important Agentforce guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers creation and deployment, but does not explain what the tool returns on success or failure, nor does it mention whether it overwrites an existing class. Given the absence of an output schema, these gaps are noticeable. The Agentforce example adds depth, but deployment outcomes and side effects are left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 a concrete example of a valid classBody for Agentforce actions, including @InvocableMethod details, which clarifies the expected source code format beyond the schema's generic 'Full Apex class source code including the class declaration.' No additional detail for className or apiVersion, but the example is meaningful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Creates and deploys an Apex class to the Salesforce org using the Metadata API.' It also distinguishes from siblings by explicitly enumerating supported class types (service, controller, batch, etc.) and noting 'any type of Apex class', which separates it from tools like sf_create_apex_trigger or sf_create_apex_email_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use for any type of Apex class: service classes, controllers, batch classes, ...' and includes a special case for Agentforce agent actions. However, it does not mention alternatives or exclusions (e.g., when to use sf_create_apex_test_class or sf_create_apex_trigger instead), so it lacks explicit when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the operation is not read-only and is idempotent, which aligns with the description's 'Creates and deploys' statement. The description adds context by mentioning optional test execution after deployment and the production coverage requirement, which goes beyond the annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with each sentence delivering distinct value: purpose, required input, optional behavior, deployment context, and use cases. It is front-loaded with the core purpose and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description covers the core behavior, use case, and an important constraint (75% code coverage for production). It omits minor details like API versioning or deployment failure behavior, but these are either in the schema or not critical. It is adequately complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 reinforces the classBody parameter ('Provide the full test class source code') and runAfterDeploy ('Optionally run the tests immediately after deployment'), but these mainly echo schema descriptions. It does not add significant new semantics beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Creates and deploys an Apex Test Class (annotated with @isTest).' It uses a specific verb and resource, and distinguishes it from sibling tools like sf_create_apex_class (which creates regular Apex classes) by emphasizing the test class annotation and deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Use for unit testing Apex classes, triggers, and business logic.' It also notes that test classes are required for production deployments, implying necessity. However, it does not explicitly name alternative tools or exclusion scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: 'Only one rule can be active at a time per object' and 'Rule entries are evaluated top-to-bottom and the first match wins.' These disclose important implications of the operation. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary purpose, followed by essential behavioral context. No filler or redundant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested ruleEntries object) and no output schema, the description covers the core concept and key constraints (one active rule, top-to-bottom evaluation) well. It doesn't explain return values, but the schema and annotations cover the rest sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameters. The description does not add parameter-specific semantics beyond what's in the schema, though it implies meaning for the 'active' parameter via the one-active-rule constraint. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates an Assignment Rule for Leads or Cases') with a specific resource and scope. It explains the purpose of assignment rules ('automatically route new records to the appropriate owner') which distinguishes it from sibling rule-creation tools like escalation rules or sharing rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool: when creating assignment rules for Leads or Cases to auto-route records. It explains the key behavior but does not explicitly name alternative tools or mention when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds context beyond these by explaining the generation output (.evt scaffold), the two event types, and firing mechanisms. It does not contradict annotations, though it could disclose more about side effects or file handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: the first states the core purpose, the second explains the event types, and the third shows practical usage. No fluff, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a scaffold generator with 4 parameters, no output schema, and rich annotations, the description covers the essential aspects: what it generates, the two event variants, and how they are used. It lacks explicit exclusions or alternative tool references, but is otherwise complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so the description adds minimal extra meaning. It mentions 'Define event attributes with names and types', which slightly reinforces the attributes parameter, but the schema already documents this thoroughly. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Generates an Aura Event scaffold (.evt file content)', using a specific verb and resource. It distinguishes from siblings like sf_create_platform_event by detailing COMPONENT vs APPLICATION events, which are Aura-specific concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: for creating Aura events, with explanation of event propagation and broadcasting. It doesn't explicitly name alternatives or exclusions, but the Aura-specific terminology and .evt file reference imply its niche well enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly=false, idempotent=true, etc. The description adds context about Metadata API usage and supported providers but does not disclose potential side effects, conflict behavior, or deployment details. This is adequate but not rich. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no filler. Each sentence earns its place: what it does, supported types, key inputs/options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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. The description covers the essential context: purpose, provider types, required credentials, and optional handler. While it doesn't describe return values or additional optional params (defaultScopes, customErrorUrl), the schema covers those, so the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by explaining the purpose of consumerKey/consumerSecret ('from the external identity provider') and registrationHandler ('custom user provisioning logic'). It reinforces the providerType enum without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Creates') and resource ('Auth Provider in Salesforce') and clarifies the purpose (SSO or social login via Metadata API). It lists supported provider types, distinguishing it from other creation tools in the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool ('for SSO or social login') and specifies the input requirements ('Provide the consumer key and secret'). However, it does not explicitly mention alternatives or when not to use it, though the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds valuable context about the rule's behavior (sending confirmation email) and how rule entries select templates based on criteria. This goes beyond the annotations but does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core action, and contains no filler or repetitive statements. Every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a detailed schema and clear annotations, the description sufficiently covers the tool's purpose, behavior, and usage context. No output schema is present, but the create action is well-defined and the agent has enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameters, so the base line is 3. The description adds a high-level explanation that rule entries map criteria to templates, but this largely paraphrases schema descriptions rather than providing new details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an Auto-Response Rule for Web-to-Lead or Web-to-Case, which is a specific verb+resource combination. It distinguishes this from sibling tools by naming the exact use case (automatic confirmation email upon web form submission).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear scenario for when to use the tool: when a lead/case is created via a web form and an automatic email should be sent. It does not explicitly mention alternatives or exclusion conditions, but the context is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by mentioning 'via the Metadata API' and the integration context with other Salesforce components, which goes beyond the structured annotations. It doesn't detail permissions or edge cases, so it's not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the primary action and method, and contains no filler. Every sentence adds relevant information about what the tool does and why it's used.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the comprehensive input schema and annotations, the description adequately covers the tool's purpose and business context. It explains the relationship with SLA-related features but doesn't address return values (no output schema exists) or explicitly mention the optional isDefault parameter, though the schema covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters (name, timeZone, days, isActive, isDefault) are already documented. The description loosely references 'working hours for each day, time zone, and active/inactive days' but adds no new parameter-level detail beyond what the schema provides, earning the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Creates Business Hours in Salesforce via the Metadata API,' providing a specific verb, resource, and method. This distinguishes it from siblings like sf_create_holiday or sf_create_entitlement_process, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that Business Hours are used with Entitlement Processes, Escalation Rules, and Holidays to calculate SLA milestones, giving clear context on when this tool is relevant. However, it doesn't explicitly state when not to use it or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains what Compact Layouts do (define fields shown in highlights panels, mobile, related lists) and notes the 10-field limit, adding meaningful context. It does not contradict annotations, and the idempotent/read-only hints are consistent. It does not detail default-setting behavior, but the annotations already cover safety profile, so this is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and then add context/usage. Every word earns its place, with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no output schema, and strong sibling context, the description covers the essential 'what' and 'when' adequately. It could mention setAsDefault or behavior on existing layouts, but the schema covers parameters and the usage guidance is sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no new parameter-level details beyond what the schema already documents; it mentions the 10-field max but that is also in the schema. It does not compensate further, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Creates a Compact Layout for a Salesforce object.' It clearly defines what a Compact Layout is and where it appears, distinguishing it from other Salesforce metadata creation tools like page layouts or search layouts. The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 when you want to surface the most important fields at a glance.' This provides clear context though it does not mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and idempotent hint. The description adds that the operation uses the Metadata API and enforces the '__c' suffix rule, which are useful behavioral constraints not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and no filler. The second sentence provides selection guidance and a naming constraint efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and annotations that clarify safety, the description provides sufficient context for selection and invocation. It clearly states what it creates and when to use it, though it doesn't describe return values or deployment behavior—acceptable given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 13 parameters. The description's naming rule is already embedded in the fullName pattern, so it adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specifically identifies the action ('Creates') and resource ('Salesforce Custom Object'), and distinguishes from siblings like sf_create_external_object by specifying the custom object type. The phrase 'using the Metadata API' adds technical context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger: 'Use this when a user asks to create a new object, entity, or table in Salesforce.' This clearly indicates when to select the tool, though it doesn't discuss exclusions or mention alternatives like external objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful context beyond annotations, such as the folder path format ('FolderName/DashboardName') and the requirement that components be powered by existing reports. There is no contradiction with the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, then providing usage context. Every sentence adds value without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary purpose, usage context, and key prerequisites. It does not mention success responses or error conditions, but given the lack of an output schema and the presence of annotations covering safety, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully describes all parameters. The description's mention of folder format and report linkage adds minimal extra meaning, as these are already captured in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Creates a Salesforce Dashboard' and enumerates component types (charts, metrics, tables, gauges), clearly distinguishing it from sibling sf_update_dashboard. The verb and resource 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case ('Use when a team needs a visual summary of their metrics') and implies prerequisites (components linked to existing reports). However, it does not explicitly mention alternatives or exclusion conditions, though the clear 'create' focus differentiates from update tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a mutating, non-idempotent operation. The description adds useful behavioral context—URL paths are relative to the site prefix and pages can be standard or custom—but does not disclose potential conflicts, error behavior, or prerequisites beyond needing an existing site.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, then the key distinctions and usage timeline. No redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter create tool with no output schema, the description supplies enough to select and invoke: what it creates, the supported types, URL semantics, and correct usage ordering. It doesn't explain return values or duplicate handling, but those are not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with basic descriptions, so baseline is 3. Description adds meaningful semantics by explaining that 'standard' page types include home, login, profile, object detail, and object list, and by clarifying that url is relative to the site's URL prefix.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific action verb 'Creates a page within an existing Experience Cloud site,' identifying both resource (page) and scope (existing site). It further differentiates from sibling tools by listing page types (standard vs custom), clarifying it is not for site creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit sequencing: 'Use after creating the site to add additional pages for different content sections,' which tells the agent when to invoke relative to site creation. It does not name an alternative tool or specify when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond annotations: it outlines supported protocol types (OData 2.0/4.0, SimpleURL, Apex) and states the result ('appears as External Objects (__x) in Salesforce'). However, it does not disclose preconditions such as endpoint accessibility, authentication requirements, or failure behavior (e.g., what happens if the endpoint is unreachable). The idempotentHint=true annotation is not contradicted by the description, though the duplicate creation behavior is not covered. Given annotations cover basic read/write, this is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no redundant information. The key term 'Salesforce Connect' appears early, and the description is front-loaded with the verb and object. Each sentence adds distinct value: purpose, supported types, outcome. This is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with no output schema, the description provides a solid overview. It covers the resource type, supported protocols, and the resulting artifact (External Objects). However, it omits details about return values, any parameter dependencies (e.g., authentication fields required for OData), and potential side effects like connectivity checks. These are not explained in the schema either, leaving a moderate gap. Overall, it is sufficiently complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 meaning by mapping the 'type' parameter to real-world adapters (OData 2.0/4.0, SimpleURL, Apex) and clarifying the purpose of an endpoint. It also explains the ultimate effect (External Objects) which relates to the 'type' and 'endpoint' parameters. Since it goes beyond the schema's descriptions, a 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates an External Data Source for Salesforce Connect', clearly stating the action and resource. It further specifies read-write access to external data and distinguishes this from related sibling tools like create_external_object by noting it appears as External Objects. This is 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'enabling read-write access to data stored outside Salesforce without importing it' tells when to use this tool. It does not explicitly name alternatives, but the sibling list includes create_remote_site_setting or create_external_object; the description's mention of Salesforce Connect and supported adapters gives enough context to select it over those. However, there are no explicit exclusions or 'use instead' statements, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false), non-destructive (destructiveHint=false), and idempotent (idempotentHint=true). The description adds useful behavioral detail: 'The field is also automatically marked as unique.' This goes beyond what annotations provide and informs the agent of an important side effect, without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence immediately states the tool's purpose, followed by a compact bullet-style list of parameters. Every sentence earns its place, with no fluff or repetition of the tool name. The structure is easy to scan and digest.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately simple with six well-documented parameters and no output schema. The description covers the core purpose, key behavioral side effect (auto-unique), and use case. However, it omits potential prerequisites (e.g., object existence, field name uniqueness) and error handling. Despite these gaps, the annotations and schema fill in enough that the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats parameter names with brief explanations (e.g., 'fullName: field API name ending in __c'), but these add minimal value over the schema's own detailed descriptions. The only slight addition is clarifying that 'length' is for Text fields, but this is also inferable from the schema's maximum/minimum constraints. No new semantic relationships are described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Creates a custom field with externalId=true on a Salesforce object,' which is a specific verb+resource combination. It distinguishes itself from sibling tools like sf_create_custom_field by emphasizing the externalId=true and unique field characteristics, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'External ID fields can be used for upsert operations and integration matching.' This indicates the intended use case. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, indicating a non-destructive write operation. The description adds valuable context that the created page is not automatically activated or assigned, but must be done later via Setup > Lightning App Builder. This goes beyond the annotations by clarifying the post-creation workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the purpose, and each sentence provides distinct useful information (purpose, supported types + requirements, post-activation note). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and full schema with all parameters described, the description covers the essential aspects: creation, page types, template, conditional object API name, and activation path. It does not explain error behavior or response format, but no output schema exists and annotations cover safety attributes, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats the template examples and the conditional requirement for objectApiName that are already present in the schema descriptions. It does not add substantive parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Lightning App Builder page (FlexiPage) via the Metadata API, which is a specific verb+resource. It also lists supported page types (AppPage, RecordPage, HomePage), distinguishing it from sibling tools like sf_create_lightning_app or sf_create_experience_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains the supported page types, requires the object API name for RecordPage, and notes that pages are activated later via Setup. However, it does not explicitly contrast with alternative tools or state when not to use this tool, so it lacks the 'excluded alternatives' component.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (non-read, non-destructive, idempotent, open-world). The description adds behavioral context beyond annotations by explaining placement ('accessible from the global navigation bar') and that it appears in the global quick actions menu, which is useful for understanding the scope and effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loading the core purpose and then adding supported types and the key distinction from object-specific actions. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 params but no output schema. The description explains the global action concept and supported types, while the schema covers parameter details. It falls just short of perfect completeness because it doesn't clarify conditional parameter requirements (e.g., which params apply per action type) beyond the schema's brief note on targetObject.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description only restates the action type enum (Create, LogACall, SendEmail, Canvas) and doesn't add new semantics beyond what the schema already provides for naming conventions or conditional parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a global quick action, specifies where it appears (global navigation bar), and explicitly distinguishes it from object-specific actions via 'Global actions are not tied to a specific object.' This differentiates it from the sibling tool sf_create_quick_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by emphasizing 'global' and 'not tied to a specific object,' which contrasts with object-level quick actions. However, it does not explicitly name an alternative tool or state 'use sf_create_quick_action for object-specific actions,' so it stops short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive. The description adds a valuable behavioral trait: 'Any change to the Global Value Set is reflected in all fields that use it,' which goes beyond the annotations. It also reinforces the naming convention, though that is already in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loads the purpose, and uses clear, non-redundant language. Every sentence adds value: definition, behavioral implication, and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 params, no output schema), the description covers the essential context: what it creates, when to use it, and a key naming constraint. It does not explain the return value, but that is likely standard for create operations and not necessary for selection. Overall it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameters. The only parameter-specific note in the description is the fullName __gvs requirement, which is redundant with the schema pattern. No additional semantic value is added for the other parameters, justifying the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Creates a Global Value Set' and clarifies it as a 'shared picklist definition'. It distinguishes this from sibling tools like sf_create_custom_field or sf_add_picklist_values by emphasizing the multi-object sharing and synchronized behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit use case: 'Use when the same set of values... should be shared and kept in sync across multiple objects.' This clearly indicates applicability, though it does not explicitly name alternatives or state when not to use it, leaving a slight gap in exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, idempotent, and non-destructive. The description adds valuable behavior details: file goes to __tests__ subfolder and is deployed via Metadata API. It does not state overwrite behavior, but the idempotent hint partially covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by a brief parameter list. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, where the output is placed, deployment method, and conventions. With no output schema, this is largely sufficient. It could mention prerequisites more explicitly but is adequate for a focused creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats parameter names and examples already in the schema, adding no substantial new semantics beyond the structured definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Creates') and resource ('Jest test file for an existing LWC component'), and includes placement and deployment details. This clearly distinguishes it from sibling tools like sf_create_lwc and sf_create_apex_test_class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an existing LWC component' implies the appropriate use case (testing an already-created LWC) and sets the context. It does not explicitly name alternatives or exclusion conditions, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive, open-world, and idempotent behavior. The description adds meaningful context by stating that credentials are stored securely, listing supported auth protocols, and hinting at the companion remote site setting. It does not contradict the annotations, and it adds value beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the primary purpose. Every sentence adds value: the first defines the tool, the second explains its security benefit, and the third gives a concrete companion tool. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the high-level purpose, security model, auth protocols, and companion tool, which is strong for a create operation with a rich schema. However, there is no output schema and the description does not mention what the tool returns (e.g., the created credential's ID), leaving that gap for the agent to discover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already fully documented with names, types, enums, and examples. The description adds only a broad mention of protocols ('Basic (username/password), OAuth') which mirrors the schema enum. This is helpful but not essential, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Creates a Named Credential for making authenticated callouts to external systems from Apex or Flows.' This clearly distinguishes it from other create tools by focusing on callout authentication and credential storage. It also differentiates from the sibling sf_create_remote_site_setting by explaining the complementary relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: authenticated callouts from Apex or Flows, and explicitly says to pair with sf_create_remote_site_setting to also allow the URL. It does not provide explicit 'when not to use' or contrast with alternatives like sf_create_auth_provider, but the intended use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint false) and not destructive. The description adds useful behavioral context: it optionally adds components immediately, returns the change set ID and a Setup link, and explains the sandbox-to-production deployment purpose. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action, then optional behavior, output, and usage guidance. Every sentence contributes value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex, but the description covers the core action, optional component inclusion, return value, and deployment context. It does not mention error scenarios or prerequisites (e.g., requiring a connected org), but given the schema and annotations, it is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 three parameters. The description adds context by mentioning 'Optionally adds specified components immediately,' which clarifies the components parameter's effect, but it does not elaborate on name/description nuances. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an Outbound Change Set, a container for metadata components, and distinguishes it from related tools like adding to an existing change set or deploying metadata. The verb 'creates' plus the resource 'Outbound Change Set' is 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context: 'Use this before deploying to production when using the change set deployment model.' It does not explicitly mention alternatives or when-not-to-use, but the context is clear enough to guide the agent, especially with sibling tools like sf_add_to_change_set and sf_deploy_metadata available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral detail beyond the annotations: the configuration must be assigned via Profile or Permission Set after creation, implying the tool does not auto-assign. Annotations already declare readOnlyHint false, idempotentHint true, and destructiveHint false, and the description does not contradict them. This extra context is valuable for setting expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear first sentence states the purpose, followed by concise bullet definitions for three key parameters, and a final operational note. Every line earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool without an output schema, the description adequately covers purpose, key parameters, and the post-creation assignment step. It does not mention the optional per-channel capacity object in serviceChannels, but the schema provides that detail. Overall, the description is reasonably complete for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description compensates by explaining capacity, serviceChannels, and allowAgentsToChangeStatus. However, it does not explain label or description parameters, leaving some gap. The provided explanations add meaningful semantics beyond the schema, but the coverage is not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Presence Configuration (PresenceUserConfig), which controls service channels and agent work capacity. It uses the specific verb 'Creates' and identifies the resource, distinguishing it from related siblings like sf_create_presence_status and sf_assign_presence_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful operational context: it explains what the configuration does (channel handling and capacity) and notes that assignment is done separately via Profile or Permission Set. It does not explicitly name alternatives or exclusions, but the context sufficiently implies when this tool would be relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is non-read-only, non-idempotent, and non-destructive. The description adds the behavioral nuance that it creates a single record system-wide via the REST API, but does not disclose details like return value, error conditions, or side effects. The added value over annotations is modest, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and includes a practical alternative in the second sentence. There is no redundancy or filler; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter create tool with no output schema, the description fully covers the key contextual points: the operation type, the transport, required inputs, and the bulk alternative. It does not mention the return value, but for an obvious create operation that is a minor gap; the description is otherwise complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both fields and objectApiName documented with examples. The description simply reiterates the need to provide an object API name and fields object, adding no new meaning beyond the schema. Baseline 3 is warranted when the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Creates a single SObject record'), the resource ('via the Salesforce REST API'), and distinguishes from sibling tools by contrasting with bulk creation. The verb 'Creates' and the explicit 'single' vs. bulk distinction leave no ambiguity about what this tool does relative to other create-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: it is for creating a single record, and explicitly says 'For bulk creation (100+ records), use sf_bulk_import_records instead.' This names an alternative tool and specifies the boundary, matching the high standard of the TDQS 4.3 example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, idempotent write operation. Description adds useful context about Salesforce blocking outbound HTTP by default and the role of this setting, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a purpose: action, motivation, and usage note. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with full schema coverage and annotations. Description explains the broad context and relationship to named credentials, making it adequately complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 6 parameters with descriptions, so the description doesn't need to add parameter details. It adds no extra parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it creates a Remote Site Setting to allow external URLs for Apex callouts, distinguishing it from generic create tools and noting its role in enabling outbound calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's required for any external API callout from Apex or Flows, and recommends pairing with sf_create_named_credential for authenticated callouts, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is write-oriented, non-destructive, and idempotent. The description adds useful behavioral context beyond annotations, such as how roles affect record visibility ('Roles control record visibility — users in higher roles see records owned by subordinate-role users') and the bulk 'single call' behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: it starts with the core action, adds important conceptual context, then lists the parameters in a clean, readable format. Every sentence earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one input parameter, no output schema), the description is complete: it covers purpose, usage context, and parameter semantics. It could optionally mention conflict behavior with existing roles, but the annotations cover idempotency, and the lack of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameter descriptions, so the baseline is 3. The description restates the schema's parameter details (fullName, name, parentRole, description) and adds an example API name ('VP_Sales'), but this is marginal extra value rather than significant new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Creates multiple Salesforce roles in the role hierarchy in a single call.' It also distinguishes itself from siblings by emphasizing the bulk aspect ('Use to set up an entire hierarchy at once'), which separates it from the singular sf_create_role tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use to set up an entire hierarchy at once.' This tells the agent when to choose this tool over a single-role creation tool. However, it does not explicitly mention when not to use it or name alternative tools for single-role creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds useful method context ('via the Metadata API') and enumerates supported identity types, which goes beyond the schema. It does not mention potential side effects such as overwriting an existing configuration, deployment latency, or API-related limitations, so transparency is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly three sentences, with the first sentence front-loading the primary action. Each sentence earns its place: purpose and method, required inputs, and supported identity types plus use case. There is no redundant or padded wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All required parameters are identified in the description, and the use case is clear. Since there is no output schema, the description does not need to explain return values. It could mention asynchronous Metadata API behavior or permissions, but for a create operation the description provides sufficient context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for all 10 parameters with individual descriptions. The description adds semantic value by grouping the key required inputs ('issuer URL, base64-encoded IdP certificate, login URL') and calling out 'user identity mapping settings,' which maps to identityType, identityLocation, and attributeName. This contextual grouping is helpful beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Creates a SAML Single Sign-On (SSO) configuration in Salesforce via the Metadata API.' This clearly distinguishes it from sibling tools like sf_create_auth_provider by naming the exact artifact. The inclusion of supported identity types further reinforces its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the intended use case: 'Used to enable SAML 2.0 federation with external identity providers.' This gives the agent clear context for when the tool should be called. However, it does not name alternative tools or provide exclusions, so it falls short of full when-to-use vs alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds valuable behavioral context beyond annotations: the creation is asynchronous and requires monitoring via a sibling tool. Also discloses the use of Tooling API and optional Apex class execution. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences. The first sentence states the core action and API, the second lists supported types, and the third explains asynchronous behavior with a pointer to the monitoring tool. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, the description covers the essential workflow: what it creates, supported types, optional Apex class, and async monitoring. It does not mention prerequisites like Dev Hub access or return value details, but the guidance to use sf_list_sandboxes fills the main gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptive parameter docs, so baseline is 3. The description mentions sandbox types and optional Apex class, but these are already clear in the schema. It does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a new sandbox org via the Tooling API (SandboxInfo object), listing supported types. The verb 'creates' plus the resource and API uniquely identify the action, distinguishing it from refresh/monitor siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to sf_list_sandboxes for monitoring the asynchronous creation. Provides clear context for when to use the tool, but does not discuss when not to use it or mention alternatives like sf_refresh_sandbox for existing sandboxes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds a prerequisite and an example cron expression, but doesn't disclose additional behavioral traits like error handling or what happens on duplicate job names. It doesn't contradict the annotations, but information beyond same is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the purpose front-loaded, followed by usage context and a concrete example. Every sentence adds information, making it appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple scheduled-job creation tool with no output schema, the description covers the core purpose, use cases, prerequisite, and an example. It doesn't discuss error conditions or validation, but given the annotations and sibling context, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by stating 'The Apex class must already exist in the org' for className and providing an example cron expression that clarifies the format. While jobName gets no extra detail, the additional context for the other two params justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Schedules an Apex class that implements the Schedulable interface to run on a cron schedule.' It clearly identifies the resource (Apex class) and distinguishes from sibling tools like sf_create_scheduled_flow by focusing on Apex classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases: 'batch processing, nightly data cleanup, report generation, or any periodic automation.' It also provides a prerequisite ('The Apex class must already exist in the org'), giving clear context. However, it doesn't explicitly mention alternatives or when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given annotations already indicate this is a write operation (readOnlyHint=false), non-destructive (destructiveHint=false), and idempotent (idempotentHint=true), the description adds useful behavioral context about isActive affecting scheduling availability and operatingHoursName requiring an existing record. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: an introductory sentence defines the tool, followed by brief, clear explanations of key parameters. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter creation tool with no output schema, the description covers the main purpose, the key params (isActive, operatingHoursName, address), and notes a prerequisite (existing OperatingHours record). It does not explain the required 'label' parameter or return value, but this is reasonably complete given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%, so the description must compensate. It explains isActive, operatingHoursName, and address fields, but does not describe the required 'label' parameter or individual address field purposes. It adds partial value beyond the schema but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a Service Territory for Field Service Lightning' with a specific verb and resource. It also differentiates from the sibling 'sf_create_territory' by specifying 'Service Territory' and 'Field Service Lightning', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on what territories are and explains how isActive and operatingHoursName affect usage. However, it does not explicitly mention when to use this tool over alternatives like sf_create_territory, so it lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavior beyond annotations: it reveals the tool is an upsert ('Creates or updates'), explains the key formula semantics (TRUE = invalid), and names the API method (Metadata API). Annotations already cover read-only/destructive/idempotent flags, so the description complements rather than repeats them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: the first states the action and scope, the second clarifies the core formula behavior, and the third gives the primary use case. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a fully described schema and solid annotations, the description is adequately complete. It covers the main behavioral nuance (upsert and formula direction) and use case. It could optionally mention permissions or deployment impact, but the lack is not a glaring gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions errorConditionFormula semantics, but this is essentially identical to the schema description and does not add extra parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Creates or updates') and resource ('Salesforce Validation Rule') plus scope ('on any object via the Metadata API'). It clearly distinguishes from sibling tools by naming the metadata type and its use for data quality enforcement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use for data quality enforcement' provides clear context for when to invoke the tool, but it does not explicitly exclude alternatives or name sibling tools (e.g., workflow rules) for comparison. Thus it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds critical context: 'permanently removes the org and all its data', highlighting irreversibility. This adds value beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description is concise and front-loaded in two sentences. However, the parameter list duplicates schema information, which is mildly redundant but not severely bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the action, the permanent consequence, and the appropriate time to use it. No significant information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both alias and noPrompt. The description repeats these parameter descriptions verbatim without adding additional meaning, so it does not exceed the baseline set by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Deletes' with the resource 'Salesforce scratch org' and specifies 'by alias'. It also explains the permanent removal of data, clearly distinguishing it from sibling tools like sf_create_scratch_org.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context with 'Use when finished with development or testing to free up scratch org allocations.' However, it does not mention when not to use or suggest alternatives, so it lacks full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the annotations by noting that code runs in the authenticated user's context and that the tool returns compile errors, runtime exceptions, and debug log output. Annotations already indicate it is not read-only and not idempotent, so the description is consistent and provides useful extra details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, and each sentence contributes valuable information: what it does, what it returns, when to use it, and execution context. No words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately covers the return values (compile errors, runtime exceptions, debug logs). It also mentions execution context and typical use cases. It lacks information about potential side effects on data, but the annotations already signal non-read-only behavior, making this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (apexCode) with a description and example. The description adds no additional parameter-level semantics beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (executes anonymous Apex), specifies the resource (Apex code) and the exact endpoint (Tooling API executeAnonymous). It distinguishes itself from siblings by mentioning the specific use cases like one-off data fixes and debugging, which are distinct from running formal tests or querying data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool (one-off data fixes, testing snippets, creating test data, running utilities, debugging). However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds valuable context about the 24-hour retention limit and that it returns 'full text content.' This supplements the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the purpose. No filler or redundant content. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 with rich annotations and no output schema, the description adequately covers purpose, prerequisite, and a key limitation (24-hour retention). It doesn't specify error behavior, but that's not essential for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the logId parameter already described as an ApexLog record ID with 15-18 characters and retention info. The description adds 'Get the logId from sf_get_debug_logs first,' which reinforces provenance but doesn't introduce new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Retrieves the full text content of a single Apex debug log by ID.' This clearly distinguishes it from sibling tools like sf_get_debug_logs (which lists logs) by emphasizing 'single' and 'by ID.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by instructing to 'Get the logId from sf_get_debug_logs first,' which indicates the prerequisite step. It doesn't explicitly mention when not to use it, but for a straightforward retrieval tool, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds context about the API used and the returned fields, but doesn't go into details like permissions or data freshness. Minor inconsistencies (default values, status enums) slightly muddy the behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is tightly structured: purpose sentence, parameter explanations, and return summary. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only history tool, the description covers purpose, parameters, and return fields. However, the inconsistencies in defaults and status enums leave room for confusion, and it doesn't mention ordering or pagination behavior beyond the limit parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions; the description adds a max limit for 'limit' and provides human-readable status options. However, the description's default for limit (20) contradicts the schema's default (10), and the status lists differ ('Canceled' vs 'Canceling'), which undermines parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving deployment history using the Tooling API DeployRequest object, and lists what it shows (status, component counts, test results, error messages). It distinguishes itself from related tools like sf_deploy_metadata and sf_check_deploy_status by focusing on historical retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for reviewing recent deployments but does not explicitly contrast it with alternatives like sf_check_deploy_status or sf_deploy_metadata. There is no explicit when/when-not guidance or mention of alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by naming the underlying objects (FlowRecordRelation, FlowInterview), explaining the returned error context, and providing operational parameter limits (max 168 hours). These details go beyond what annotations specify, though they don't mention pagination or potential large result sets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-organized: a clear main purpose sentence, followed by a bulleted parameter list, and then return value details. Every sentence adds value and there is no redundant filler. The structure makes it easy to quickly grasp key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with three optional parameters and no output schema, the description provides sufficient context: parameters are explained with defaults and limits, and the return fields are enumerated. The description fully compensates for the lack of an output schema, making the tool's behavior predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description introduces a critical inconsistency: it refers to 'lookbackHours' while the schema defines 'hoursBack'. An agent following the description might attempt to use a non-existent parameter. The description does add the max=168 constraint not present in the schema, but the naming mismatch outweighs this benefit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Retrieves Flow interview fault records from the FlowRecordRelation and FlowInterview objects.' It names specific source objects, mentions runtime errors, and lists the returned fields (fault message, record, flow name, start time). This distinguishes it from sibling tools like debug logs or event logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates when to use the tool: to see flows that have errored at runtime. It implies this is the go-to for Flow error diagnosis, but doesn't explicitly name alternatives or state when not to use it. Given the sibling list includes debugging tools, more explicit guidance would help, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it returns configuration including elements and activation status, but it does not specify return format, error behavior, or API constraints. With strong annotation coverage, the added behavioral context is adequate but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and object. Every word adds value: it covers the resource, the contents of the retrieval, and the identifier. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only retrieval tool with only two parameters and no output schema, the description provides a complete high-level picture: what is retrieved, what is included, and how the target is identified. It does not describe the response structure or edge cases, but given the tool's simplicity and the strong annotations, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions for procedureName or subType (schema coverage 0%). The description compensates by stating the procedure is 'Identified by procedureName + subType', conveying that these two parameters together form a composite key. This adds meaningful semantics beyond the bare schema, though it does not explain the meaning or allowed values of subType.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieves') and identifies the exact resource ('configuration of an Integration Procedure') along with the included details (elements and activation status). It also names the unique identifier (procedureName + subType), clearly distinguishing it from sibling tools like sf_update_integration_procedure or sf_activate_integration_procedure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for retrieving configuration rather than modifying or creating, which provides clear usage context. It does not explicitly mention alternatives or state when not to use it, but the read-oriented purpose is unambiguous given the siblings focused on update/activate/create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the read-only, idempotent nature. The description adds behavioral detail beyond annotations: it returns all limits sorted by percent used, and describes the output fields (name, remaining, max, percentUsed). It doesn't mention error cases or response size, but for a safe read tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences plus a bulleted use-case list. It front-loads the main action, then adds useful context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, rich annotations, and complete parameter schema, the description covers the essential return format and use cases. It doesn't discuss edge cases like filtering case-sensitivity or empty responses, but these are minor gaps for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single optional 'filter' parameter is described in the schema). The description itself doesn't elaborate on the filter behavior; it only says 'Returns all limits,' while the schema already documents the substring match. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Retrieves current API and governor limit usage') and names the resource ('Salesforce Limits REST API'), clearly distinguishing it from the creation/management tools in the sibling list. It also states the exact return type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Useful for' list provides explicit scenarios (checking API call usage, monitoring storage, etc.) that tell an agent when to invoke this tool. It lacks explicit exclusions or named alternatives, so it doesn't reach 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond this: it specifies the 6-month data window, the fields returned (date, username, section, action, display), and example section filters. It does not contradict annotations and provides practical behavioral details, but it omits details like pagination or access requirements, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear opening sentence, a short list of return fields, section filter examples, and bulleted use cases. Every sentence contributes useful information without fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a query tool with no output schema, the description adequately covers the return fields, use cases, and the 6-month limit. It does not mention pagination or error handling, but those are not critical for a read-only query tool with a limit parameter. Overall, it provides enough context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage with descriptions for all five parameters. The description adds some extra meaning by giving section filter examples and mentioning the 6-month window, which contextualizes startDate/endDate. However, the schema already carries the main semantic load, so this is a baseline 3 with minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Queries the SetupAuditTrail object to see who made what configuration changes to the org, and when.' This includes a specific verb (queries), a resource (SetupAuditTrail object), and the purpose (track configuration changes). It also provides concrete use cases and distinguishes itself from other audit-related tools by focusing on setup audit trail data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context through 'Useful for:' bullets (security audits, debugging configuration changes, compliance reporting). It also mentions the 6-month coverage window, implying when this tool is appropriate. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this with 'read-only advisory tool — does not modify the org' and adds behavioral details about the optional parameters (componentName for context, checklistOnly to return only checklist items). This adds useful context beyond annotations, though it doesn't describe the output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences plus parameter lines), with the core purpose stated first and supporting details following. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple advisory tool with read-only annotations and no output schema, the description adequately covers the tool's behavior, scope, and parameter effects. It doesn't specify the exact output format, but that is less critical for a guidance tool. The description is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage). The description repeats the schema descriptions almost verbatim, adding minimal new meaning (e.g., 'for context'). The schema carries the parameter documentation burden, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and clearly identifies the resource ('guidance and a checklist for LWC accessibility best practices') and scope (ARIA attributes, keyboard navigation, focus management, screen reader support). It is distinct from sibling tools that create or modify LWC components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the tool as a read-only advisory tool ('does not modify the org'), making its context clear. However, it does not mention alternative tools or state when to prefer this over other LWC-related tools, though it is unique among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds the meaning of the resolution strategies and the prerequisite. However, it doesn't describe any side effects, return values, or what happens to the conflict record after resolution. With annotations doing the heavy lifting, this is acceptable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence for the main action and a second paragraph for parameter details. No wasted words, and the information is front-loaded. It earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the core action, the prerequisite, and parameter semantics. It does not describe the return value or postconditions, but given the tool's simplicity and the presence of annotations, it is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds critical semantics by explaining the exact meaning of each resolution enum value ('ours' = keep our changes, 'theirs' = accept incoming, 'manual' = already resolved). This goes beyond the schema's bare field descriptions and helps the agent choose correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Marks') and clearly identifies the resource ('merge conflict in DevOps Center'). It also distinguishes itself from sibling tools like sf_detect_devops_merge_conflict by focusing on resolution. The resolution strategy parameter is explicitly explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use after manually resolving conflicts in the source control system.' This clearly indicates the prerequisite and context. It doesn't mention alternatives or exclusions, but for a niche resolution action, the usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnly/idempotent annotations by explaining that it waits for the async retrieve, unpacks the zip, and truncates large files. This is valuable transparency, though it could mention error handling or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and contains only useful information in three sentences. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the async behavior, return format (file path and source), and truncation caveat, which is appropriate given no output schema. It could be more complete with error scenarios or limits, but overall is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters described. The description does not need to add parameter details and adds minimal value beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves metadata components and returns their file contents, with specific use cases like reading configuration, backing up, and verifying deployments. This distinguishes it from siblings by being a general-purpose metadata retrieval tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (read existing config, backup, check deployed state) and context for when to use. However, it does not explicitly state when not to use or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral detail beyond the annotations: it uses the Tooling API runTestsAsynchronous endpoint and polls for results. This is important for an agent to understand the potentially long-running, asynchronous nature. The annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and every sentence adds value (what it does, how it does it, when to use it). No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value (pass/fail with errors), the asynchronous mechanism, and the main use cases. With no output schema, it provides enough information for an agent to understand what to expect. It doesn't detail the full response shape, but that's acceptable given the tool's simplicity and the presence of a sibling for retrieving detailed results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter descriptions, including testClasses and waitMinutes with types, defaults, and constraints. The description adds no additional parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs Apex test classes and returns pass/fail results with errors. It uses the specific verb 'runs' and names the resource (Apex test classes), distinguishing it from the sibling tool sf_get_apex_test_results which would retrieve already-run results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: after deploying Apex code to verify coverage, or before a release for regression tests. It provides clear context but does not enumerate alternatives or explicitly state when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations by explaining the partial update semantics: 'Only provided fields are changed — omitted fields retain their current values.' Annotations convey readOnly=false and destructive=false, but the description enriches this with field-level detail and the fact that it targets an existing record.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word contributes. It clearly explains the what, how, and key behavior without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool, the description is complete: it mentions the endpoint (Salesforce REST API), the required inputs, and the most important behavioral nuance (partial update). Although there is no output schema, the tool's purpose does not demand an elaborate return contract, and the description covers the essential invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as all three parameters have descriptions in the schema. The description essentially restates the schema parameter info ('Provide the object API name, the 15 or 18 character record ID, and the fields to update') without adding any new semantic detail beyond what is already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Updates an existing SObject record by record ID via the Salesforce REST API.' It identifies the resource (SObject record), the verb (updates), and method (by record ID). This distinguishes it from sibling tools like sf_create_record, sf_delete_record, and sf_upsert_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating the need for an existing record ID and the partial-update behavior: 'Only provided fields are changed — omitted fields retain their current values.' However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: partial-update semantics ('Only fields you provide are updated') and the username-based lookup approach. It complements the idempotentHint and readOnlyHint=false without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with the purpose front-loaded. It contains no redundant wording and quickly conveys the core operation, lookup method, and partial-update behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with moderate complexity, the description covers the essential aspects: what it updates, how users are identified, and the partial-update behavior. It lacks information about error conditions or permission requirements, but the annotations provide a safety profile, and no output schema is expected for update operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of parameter descriptions, so the baseline is 3. The description's notable field list (firstName, lastName, etc.) aligns with additionalFields examples but doesn't introduce new meaning beyond what the schema's additionalFields example already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Updates an existing Salesforce user's properties via the REST API.' It lists specific updatable fields and explicitly distinguishes from creation by saying 'existing user' and by username lookup, setting it apart from generic record update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for updating existing user records by username, which is clear context. However, it does not explicitly mention when not to use it or name alternatives like sf_update_record, but the intent is sufficiently clear from the resource-specific language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating, non-destructive operation. The description adds meaningful context by defining the artifact (URL-based tab that opens external/page content) and clarifying it is a creation action, complementing the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two purposeful sentences introducing the tool and distinguishing it, followed by a concise parameter list with inline examples. No filler. The parameter list is slightly redundant with the schema, but the overall structure is efficient 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with well-annotated schema, the description covers the core context: what it creates, when to use it, how it differs from siblings, and what each parameter means. It does not explain return values or permissions, but given the 5-param schema and no output schema, the description is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 each parameter. The description's parameter list mostly repeats schema details, but it adds small clarifications like 'no spaces' for fullName and provides examples (e.g., 'https://example.com'). This slightly enhances but does not significantly exceed the schema's value, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates a Custom Web Tab (URL-based tab) that opens an external URL or web page within the Salesforce UI'—a clear verb+resource combination. It explicitly distinguishes itself from sf_create_tab, which 'creates object-based tabs,' making the unique purpose instantly apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Different from sf_create_tab which creates object-based tabs. Use when you need a navigation item that points to an external website, an internal Visualforce page by URL, or a custom web app.' This names the alternative and gives concrete use cases, fully satisfying the when-to-use vs alternatives requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and openWorld hints, readOnly false. The description adds valuable beyond-annotation context: deployment may succeed even without a license, predictions are created in Draft status, and training/activation must be done externally. It also mentions pushbackField auto-writes the score. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, parameter explanations, and an IMPORTANT callout for licensing. It's a bit longer than minimal but every sentence serves a purpose for an 11-parameter tool. The front-loaded 'Creates' statement establishes purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description covers prerequisites (license), workflow (create → train → activate), and status (Draft). It does not describe return values, but that is acceptable since no output schema exists and the rule says description needn't explain return values if output schema exists; here it's not critical. The tool's role in the larger process is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the baseline is 3. The description goes beyond the schema by giving real-world examples for predictionType (e.g., 'Will this opportunity close?'), targetField (e.g., 'IsWon'), and pushbackField (e.g., 'Win_Score__c'). It also explains the relationship between targetField and objectApiName, adding practical meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Creates an Einstein Prediction Builder prediction definition (MLPredictionDefinition metadata type).' It clearly differentiates this from sibling tools like sf_create_einstein_bot by focusing on ML prediction definitions, with detailed type examples (BinaryClassification vs Regression).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (to create the prediction definition) and explicitly warns about the Einstein Analytics license prerequisite and that training happens in Setup, not through this tool. It doesn't explicitly name alternative tools, but no close sibling exists, so the scope is adequately clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, idempotent, and non-destructive behavior. The description adds valuable context: uses Metadata API zip deploy, auto-defaults start locationX/locationY, and pre-validates three specific schema errors. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-sentence but well-structured and front-loaded: action, use case, activation, and validation notes. Every sentence carries meaningful information, though it could be slightly condensed without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description explains prerequisites (complete Flow XML), behavior (deploy and optional activation), and error-prevention validations. It is sufficient for an agent to invoke correctly, especially with sibling status-check tools like sf_check_deploy_status available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. Parameter meanings are fully documented in the schema. The description adds only marginal semantics (e.g., confirming flowXml must be complete), though the pre-validation details are more behavioral than parametric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Deploys a Salesforce Flow directly from raw XML using the Metadata API zip deploy.' It explicitly distinguishes itself from the sibling tool sf_create_flow by targeting complex flows beyond the parameter-based builder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this for complex flows that are too advanced for sf_create_flow's parameter-based builder' and mentions optional activation. This tells the agent exactly when to select this tool over the named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already handle safety traits (readOnly=false, destructive=false, idempotent=true). The description adds the 'via the Metadata API' detail and explains the relationship to Business Hours, offering useful behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, directly states the core purpose, and is well-structured with the action first. Every sentence adds value without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (8 parameters, all documented), the description provides enough context about purpose and usage. Annotations fill in safety traits, and no output schema is needed for a create operation. An agent can confidently select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 8 parameters with full descriptions (100% coverage), so the baseline is 3. The description's mention of one-time/recurring holidays and optional Business Hours association largely restates schema information without adding significant new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear action ('Creates a Holiday record in Salesforce via the Metadata API') and specifies the resource and purpose (exclude days from SLA calculations). It distinguishes itself from siblings like sf_create_business_hours by focusing on holiday records specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining that holidays are used with Business Hours to exclude days from SLA calculations, making the use case evident. It does not explicitly mention alternatives, but no direct alternative exists among siblings, so the context suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent creates, non-readonly, non-destructive. The description adds valuable context: runs in Apex context, can be invoked from various surfaces, uses the OmniScript metadata type with omniProcessType=IntegrationProcedure, and mentions activation behavior via isActive. No contradictions found; the description enriches the annotation-provided safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal but well-structured with a clear opening, technical context, and a bulleted list of element types. Every sentence contributes useful information—the element list is redundant with the schema but adds semantic clarity. It is organized and scannable, though slightly verbose for a create tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, many element types) and no output schema, the description covers the essential aspects: purpose, runtime context, invocation methods, fullName rules, element types, and activation. It does not cover error handling or permissions, but for a create operation the description is sufficiently complete to guide invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 67% of parameters with descriptions. The description adds meaningful semantics beyond the schema: it explains the fullName construction (ProcedureName_SubType), details each element type (DataRaptor, HTTPAction, etc.) beyond the bare enum, and clarifies the isActive behavior. While 'label' and 'description' parameters lack direct explanation, the overall parameter context is significantly enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Creates an OmniStudio Integration Procedure' and elaborates on what it is ('a server-side process that orchestrates data integration without UI'). This clearly distinguishes it from related tools like OmniScript creation and other integration procedure tools (update/get/activate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when an Integration Procedure is appropriate (server-side, no UI, invoked from OmniScripts/FlexCards/APIs). It implies a distinction from OmniScripts ('without UI') but does not explicitly name alternatives or exclusion cases. The context is clear enough for an agent to make a reasonable choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate this is a write operation and not idempotent, the description adds meaningful behavioral context: it can also create PricebookEntry records and that isStandard 'true only for the standard price book'. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then gives background and a compact parameter list. There is minor redundancy with the schema's parameter descriptions, but the structure is clear and each section serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema, the description covers the main action, optional sub-actions, and key constraints. It lacks details on potential errors or prerequisites (e.g., existing products), but acceptable given the tool's moderate complexity and absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds extra semantic value. For instance, it clarifies that isStandard is 'true only for the standard price book' and that products is an 'optional array of {productId, unitPrice, useStandardPrice?}' to add to the price book, enriching the parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a Pricebook2 record and optionally adds products with pricing via PricebookEntry records,' using a specific verb and resource. It distinguishes itself from sibling create_* tools by focusing on Pricebook2 and its optional related entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: 'Price books define the prices for your products' and mentions standard vs. custom price books for customer segments/regions. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=true. The description adds contextual behavior: it enables OmniChannel routing and clarifies the dependency on an existing queue and pre-created routing configuration. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short paragraphs, front-loaded with the main purpose, then workflow, then parameter clarifications. It is concise and well-structured, though parameter details are slightly redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple linking operation, the description covers the prerequisite (create routing config first), the target (existing queue), and the outcome (routed work items). No output schema exists, so return values are not needed. It lacks error conditions but is adequate for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions, and the description reinforces meaning by clarifying queueDeveloperName is the DeveloperName (not label) and routingConfigName is the API name. This adds valuable semantics beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Associates a Routing Configuration with an existing Queue' with a specific verb and both resources. It distinguishes itself from sibling tools like sf_create_routing_configuration, which creates the configuration rather than linking it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: 'After creating a Routing Configuration (sf_create_routing_configuration), use this tool to link it.' It names the prerequisite tool and explains the outcome, but does not state when not to use it or contrast with other linking tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds useful behavioral context about how capacity, priority, unitType, and pushTimeout affect routing. It does not contradict annotations, but it does not fully disclose edge cases like duplicate names. The added detail is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with a clear opening sentence followed by bullet-point explanations of key parameters. It is somewhat long but every sentence provides useful information. The structure is easy to scan, though the inaccuracies in parameter descriptions slightly mar the overall clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and no output schema, the description covers the most important parameters and provides a follow-up sibling tool reference. It is largely complete for an AI agent to invoke the tool, but the schema-description contradictions mean the agent could be misled on valid values, and some parameters (label, configName, description) are not explained in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains several parameters (routingModel, capacity, priority, unitType, pushTimeout) with concrete meanings, adding value beyond the schema. However, it contains inaccuracies: it states unitType options are 'Percentage or Throughput' while the schema enum is ['Percentage', 'Items']; it says capacity range 1–100 but schema allows 0–100; priority range 1–10 is not in the schema. These contradictions undermine the reliability of the parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Creates a Routing Configuration that defines how work items are assigned to agents.' It uses a specific verb ('creates') and resource ('Routing Configuration'), and distinguishes itself from the sibling tool sf_create_queue_routing_config by explicitly noting the post-create linking step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool and what to do next: 'After creating, link it to a queue with sf_create_queue_routing_config.' It also explains the semantics of routingModel options (LeastActive, MostAvailable, ExternalRouting) with clear definitions, helping the agent choose the correct configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readonly, non-destructive, idempotent. The description adds context by explaining the effect (cannot log in, license retained) and the use case, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a few sentences to convey purpose, behavioral context, and usage. The parameter notes are redundant with schema but not excessive. It's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean toggle, the description provides sufficient context: action, effect, use case, and parameters. No output schema is needed, and the behavior is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions. The description adds a note that the username parameter can accept either a username or userId, which is additional information beyond the schema's 'Salesforce username.' However, this could be slightly ambiguous, and the freeze parameter is already well described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool freezes or unfreezes a Salesforce user account, a specific action on a specific resource. It also distinguishes this from deactivation by noting license retention, which sets it apart from other user-management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states a use case: 'Useful for temporarily blocking access without losing data ownership.' It also contrasts with deactivation, providing guidance on 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the agent knows it is safe. The description adds valuable behavioral context: exact-name matching, Tooling API usage, and the specific return payload (body, object, status, events). This goes beyond what annotations provide, but does not discuss errors or exact-match failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the main purpose, and each sentence provides useful information without redundancy. It includes the retrieval action, return fields, and usage context in a compact manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, strong annotations, and no output schema, the description fully covers what the tool does, what it returns, and when to use it. There is no missing critical information, making it complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter triggerName with a description and example, achieving 100% schema coverage. The description reinforces 'exact name' but does not add new semantic details (e.g., case sensitivity or format) beyond the schema, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full source code of an existing Apex trigger by exact name via the Tooling API, and lists the specific returned fields (body, object, active status, trigger events). It is distinct from sibling tools like sf_create_apex_trigger or sf_get_apex_class by focusing on reading an existing Apex trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it 'before modifying a trigger' or 'when a user asks to see or explain an existing trigger.' This provides clear when-to-use guidance, but it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds useful behavioral details like return limits (20 rows per file, 3 files per call) and the requirement for Event Monitoring add-on or Agentforce debug logs, which go beyond annotation info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose sentence, event type list, return behavior, and requirements. The list is a bit long but each item is useful, and the text stays focused without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return format and limits, plus prerequisites. It could mention how to handle more than 3 files or pagination, but the core needs are met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters, but the description enriches eventType by listing common values and clarifies the effect of limit (rows per file and files per call). This adds meaningful context beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries EventLogFile for detailed activity logs, listing common event types and distinguishing it from other logging tools. The verb 'queries' and resource 'EventLogFile' 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage context for security monitoring and performance analysis, and lists event type examples that help the agent decide when to use it. It doesn't explicitly exclude alternatives but clearly implies the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and no destructive behavior. The description adds valuable context: the return record shape and the prerequisite that tracking must be enabled, as well as the 18-month retention limit. This exceeds what annotations provide without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: an opening purpose sentence, a line about return fields, brief parameter explanations, and a practical note. It is not overly verbose, though the parameter section repeats some schema info. Each section contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with 4 parameters and no output schema, the description covers the purpose, return values, and prerequisites. It does not mention ordering, pagination, or error scenarios, but given the strong annotations and schema, this is a reasonably complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of all four parameters with descriptions. The description adds extra meaning by clarifying that objectApiName must be an object with history tracking enabled and that recordId is the specific record. It does not deeply elaborate on 'limit' or 'fields' beyond the schema, but the baseline is raised slightly due to the additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Queries the {Object}History object to retrieve a field-level change history for a specific record' and lists the exact data returned (date, field, oldValue, newValue, changedBy). This distinguishes it from sibling tools like sf_query_records or sf_get_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 (field-level change history for a specific record) and includes important prerequisites (field history tracking must be enabled, 18-month retention). It does not explicitly name alternative tools or exclusion scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive. The description adds valuable behavioral context by specifying exactly what configuration data is returned (data source, fields, actions, states, activation status). No contradictions; it complements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of 17 words, front-loaded with the verb, and includes a concise enumeration of contents. No wasted words; all information is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter get tool with rich annotations, the description adequately explains the return scope (configuration elements). Since there is no output schema, the description's enumeration of returned data satisfies the need for explaining return values. The tool is simple enough that no further details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter cardName has a complete schema description ('API name of the FlexCard to retrieve'), so the schema covers 100% of parameter meaning. The tool description adds no additional information about the parameter beyond what the schema provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieves' and clearly names the resource (OmniStudio FlexCard configuration), enumerating the contained elements (data source, fields, actions, states, activation status). This distinguishes it from sibling tools like sf_create_flexcard or sf_activate_flexcard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for reading a FlexCard's configuration, and the get verb implies it is for inspection rather than modification. However, it does not explicitly mention alternatives or exclusion criteria, so it lacks the explicit when/when-not guidance that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, which the description aligns with by stating it reads and parses a file. It adds useful details about returning tool names in registration order, going beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action. Every sentence adds value, with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description states it returns tool names in order. Combined with the simplicity of a single parameter and strong annotations, the description is complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the only parameter projectDirectory fully described as an absolute path. The description does not add further semantic meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all registered tools in an MCP server project by parsing its src/index.ts file. This is a specific verb+resource combination that distinguishes it from sibling tools like sf_create_mcp_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes the tool is for auditing existing tools before adding new ones, which gives clear context for when to use it. It doesn't mention alternatives or exclusions, but the use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare read-only and idempotent, the description adds substantial behavioral detail: it retrieves class bodies via Tooling API, creates a temp workspace, cleans up afterward, requires Java 11 for certain engines, and automatically falls back to Java-free engines with a response flag. This goes far beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loaded with the core purpose, but the first sentence is quite long with a parenthetical list of engines and rules. The param descriptions are concise and add value, but the overall length is higher than strictly necessary though each sentence carries meaningful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the multi-engine nature, Java dependency, fallback behavior, and lifecycle (fetch, scan, cleanup). It does not detail the exact output format or return schema, but it does mention response flags for fallback. Given no output schema, a bit more about the scan results could improve completeness, but it is largely adequate for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both the schema and description explain classNames, maxClasses, and ruleSelector defaults. The description adds little beyond the schema, mainly reiterating defaults and the Java fallback context. Baseline 3 is appropriate given the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as running Salesforce Code Analyzer against Apex classes, listing specific engines and rules. It distinguishes itself from the sibling sf_scan_apex_antipatterns by framing itself as a real multi-engine scan on top of the lighter heuristic check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description positions the tool relative to sf_scan_apex_antipatterns, implying deeper analysis. It explains the Java-dependent engine fallback behavior, giving clear context for when certain features are unavailable. However, it does not explicitly state 'use this when X, use antipatterns when Y'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations by disclosing that this operation updates Profile metadata and that profileNames defaults to the Admin profile. The annotations already indicate non-read-only, idempotent, and non-destructive behavior, and the description aligns with these without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one introductory sentence explaining the purpose and mechanism, followed by a compact parameter list. Every sentence adds value, and there is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple configuration tool, the description covers the essential context: what it does, what it updates, and the default behavior of the optional parameter. It lacks details about return values or error conditions, but given the absence of an output schema and the straightforward action, the description is reasonably complete. A minor gap is not explicitly mentioning that the layout and record type must already exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaningful extra semantics, especially for profileNames, by stating that it defaults to the Admin profile when omitted — a detail not present in the schema. Other parameter descriptions are largely redundant but not harmful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('assigns') with a clear resource ('existing page layout' to 'specific record type on an object') and explains the mechanism ('by updating the Profile metadata'). It clearly distinguishes this tool from siblings like sf_create_page_layout or sf_create_record_type by focusing on the assignment action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to control which page layout users see for a record type) and even specifies the default behavior for profileNames. However, it does not explicitly mention when not to use it or offer alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds valuable behavioral context: it is asynchronous, returns a job ID for tracking, and deleted records go to the Recycle Bin. It also includes a cautionary note. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by a warning and return value. The parameter list is redundant with the schema but not harmful. Overall, it is appropriately sized, though the duplication slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately explains the key return value (job ID). It covers the async nature, the target resource, and the safety implication (Recycle Bin). For a bulk delete tool, this is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters ('Object API name, e.g. 'Lead'' and 'Salesforce record IDs to delete'), and schema coverage is 100%. The description simply repeats the parameter names and types without adding extra semantic detail, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (deletes), the resource (multiple records by ID), the mechanism (Bulk API 2.0, asynchronous), and the return (job ID). This distinguishes it from sibling tools like sf_delete_record (single delete) and other bulk operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for asynchronous bulk deletion, which implies use when multiple records need to be removed. However, it does not explicitly name alternatives or contrast with single-record delete or bulk import/update, so it lacks explicit exclusions. Still, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it discloses that deployment happens via Metadata API SOAP deploy, and that the trigger declaration is auto-generated so users only provide the inner body. This helps the agent understand side effects and what code is expected, complementing the idempotentHint and non-destructive annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding distinct value: purpose, user-specified parts (events/body), and key behavior (auto-generated declaration, deployment method). No fluff or repeated schema information, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a 5-parameter tool, no output schema, and annotations covering safety, the description provides enough detail for basic usage. It lacks explicit mention of return values or how to handle deployment failures, but given the tool's straightforward create/deploy nature and the presence of sibling tools like sf_check_deploy_status, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description still adds meaning by clarifying that triggerBody is only the code inside the braces, and by explicitly mentioning the event examples ('before insert, before update'). This prevents ambiguity about how the body parameter relates to the generated wrapper, which the schema alone doesn't convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates and deploys an Apex Trigger on any Salesforce object, with a specific verb ('creates and deploys'), resource ('Apex Trigger'), and scope ('any Salesforce object'). This distinguishes it from sibling tools like sf_create_apex_class or sf_get_apex_trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it explains how to specify events and body code, and that the trigger declaration is auto-generated. It doesn't explicitly name alternatives or exclusions, but the purpose is specific enough to infer when to use this tool for Apex triggers rather than other metadata creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false (write operation) and idempotentHint=true, which covers safety and idempotency. The description adds valuable context about the Metadata API and the distinction between displayed fields and availableFields: 'Specify the displayed fields (in the field set) and optionally additional available fields that users can add.' This goes beyond annotations and helps the agent understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and uses three sentences to convey what, why, and how. Every sentence adds value: the first states the main action, the second explains the concept, and the third clarifies parameter usage. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a metadata creation tool with no output schema, the description covers the essential aspects: the action, the resource type, the method, and the input structure. It does not discuss behavior on duplicate names or permission requirements, but given the 100% schema coverage and annotations, this is a minor gap. The tool is well-contextualized for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 semantic meaning to the key parameters by explaining that 'fields' are the displayed fields and 'availableFields' are optional additional fields users can add. This clarifies the distinction between the two array parameters beyond their schema descriptions, warranting a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Creates a field set on a Salesforce object via the Metadata API.' It specifies the exact resource (field set), the target (Salesforce object), and the method (Metadata API), which distinguishes it from the many other creation tools in the sibling list. It also explains the purpose of field sets, adding context beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when field sets are relevant: 'used in dynamic forms, Apex code, and LWC.' This implies appropriate use cases. It does not explicitly name alternatives or exclusions, but the context is strong enough to guide an agent on when to invoke this tool. A score of 4 is appropriate as it offers clear context without explicit alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write, idempotent, non-destructive tool; the description aligns by saying 'Creates or updates'. It adds valuable behavior warnings: Contains returns an error, Draft/Screen flows cannot be invoked by agents. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (under 120 words), front-loaded with the main purpose, and structured logically: purpose→supported types/elements→key limitation→critical Agentforce warning. Every sentence carries useful information without redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 19 parameters and nested element definitions, the description covers the highest-risk areas: flow type selection, element support, GetRecords filter restrictions, and Agentforce activation requirements. It does not detail update-replacement semantics or deployment behavior, but the rich schema and annotations cover most of the missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to restate parameter definitions. It adds cross-parameter context (e.g., flowType/status combos for Agentforce, unsupported filter operators) that is not obvious from the schema alone, improving the agent's ability to set parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates or updates a Salesforce Flow via the Metadata API', which is a specific verb+resource pairing. It further lists supported flow types and element categories, distinguishing it from more limited sibling tools like sf_create_scheduled_flow or sf_activate_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: defines which flow types are supported, explicitly warns that Contains is not supported for GetRecords, and gives a critical Agentforce requirement (AutoLaunchedFlow + Active). However, it does not name alternatives or explicitly state when to use another tool, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds behavioral context by noting 'via the Metadata API' and requiring Knowledge enabled. It also highlights the __kav naming constraint. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all informative: action + context, naming constraint, optional fields, and prerequisite. No fluff. Front-loaded with the primary verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 schema-described parameters, annotations, and no output schema, the description covers prerequisites, naming, and optional fields. It does not mention return values or deployment propagation, but given the Metadata API context and schema richness, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 explaining that fields are 'custom fields for the article type such as text or long text area fields,' which clarifies the fields parameter beyond its schema description. The __kav requirement is repeated from the schema but reinforces key semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Creates a Knowledge Article Type (a custom object for Salesforce Knowledge) via the Metadata API.' This specifies the verb, resource, and method, and distinguishes it from other create tools in the sibling list by focusing on the __kav suffix and Knowledge-specific context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an important prerequisite: 'Requires Knowledge to be enabled in the org.' It also implies the use case by mentioning article type naming and custom fields. However, it does not explicitly contrast with alternatives like sf_create_custom_object, so it stops short of a full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it reads src/index.ts, appends tool registration, and inserts code before the 'Start server' section. It also instructs to run npm run build, adding meaningful behavioral detail beyond annotations which provide no hints. This aligns with destructiveHint=false as the insertion is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The main purpose is front-loaded, and each sentence delivers necessary information: operation, required inputs, insertion location, and build instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a code-modification tool with no output schema, it covers the essential workflow: file read, code placement, and post-action build command. Missing prerequisites/error handling but schema richness and operational guidance make it fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (100% coverage), giving a baseline of 3. The description adds extra meaning by specifying the inputSchema structure as 'field names to {type, description}' and clarifying the insertion point relative to the 'Start server' marker, enhancing understanding beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a tool definition to an existing MCP server project, with a specific verb ('Adds') and resource. It distinguishes from siblings like sf_create_mcp_server (creating the server) and sf_list_mcp_tools (listing tools) by focusing on modifying an existing project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context for when to use: for existing MCP server projects, and includes an operational step ('Run npm run build after adding tools'). It doesn't explicitly list alternatives or exclusions, but the distinction from sf_create_mcp_server is implicit, giving clear context without formal exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=true, and the description adds substantial context about what the tool creates, the structure of a strategy, and how it is displayed. It does not disclose permission requirements or potential side effects, but the annotation coverage reduces the burden; the description goes beyond the annotations by explaining the strategy's components.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. It uses bullet-like lines for the strategy definition and display options, making it scannable. Each sentence adds necessary context for understanding the NBA strategy, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool creates a complex metadata type, and the description covers the key aspects: what it is, main components, where it can be displayed, and next steps after creation. It does not describe return values (no output schema) or permission requirements, but for a create tool with strong schema and annotation support, the description is sufficient for an agent to understand and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already described. The description adds extra meaning by explaining the purpose of key parameters: it defines contextObjectApiName as the record type providing context (e.g., 'Account', 'Case') and explains that recommendations come with Accept/Decline buttons and an optional Flow to execute on acceptance. This enriches the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Creates a Next Best Action (NBA) recommendation strategy (RecommendationStrategy metadata type).' This clearly distinguishes the tool from sibling creation tools by naming the exact metadata type and providing a concrete example of what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool by detailing how NBA strategies surface recommendations on record pages, communities, and chatbots, and lists supported display contexts (Einstein component, OmniScripts, FlexCards, Service Console). It also includes a post-creation step (adding the Lightning component), giving a clear usage scenario. However, it does not explicitly state when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and idempotency (idempotentHint=true). Description adds meaningful context about the Metadata API, optional path item components, and activation behavior, going beyond structured annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. Front-loads the core purpose and then elaborates on key behaviors, making it both concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no output schema, the description explains the main configuration elements (path items, activation) and aligns with annotations. It doesn't cover permissions or failure modes, but the annotations handle safety essentials, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% coverage, so baseline is 3. Description adds relational semantics by explaining that pathItems correspond to each picklist value and can include guidance text, info titles, and key fields, plus linking objectName and fieldName to a picklist field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the specific verb 'Creates' with resource 'Path Assistant' and context 'for a Salesforce object picklist field via the Metadata API'. This distinguishes it from sibling creation tools and matches the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage context (creating a path assistant for a picklist field) and mentions activation, but does not explicitly compare with alternatives or provide exclusions. Clear context is present, satisfying a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-readonly, idempotent, non-destructive operation. The description adds useful behavioral details: clients subscribe via CometD, and notifications are filtered by SOQL and operations. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, and every sentence adds value. No fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 2 required, and no output schema, the description adequately covers the core behavior and configuration. It mentions the subscription path and configurable operations. The only gap is no mention of the response/return value, but for a create operation it is less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides 100% parameter descriptions, so baseline is 3. The description adds conceptual meaning by explaining that the SOQL query filters records and the operations/fields control which notifications trigger, which helps understand the overall mechanism beyond individual parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb ('Creates') and specific resource ('Streaming API PushTopic') with a clear purpose ('real-time record change notifications'). It is distinct from sibling tools, all of which create different Salesforce artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool (when real-time notifications on record changes are needed) and describes the mechanism (CometD subscription). It does not name alternative tools, but the use case is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds meaningful context by explaining what each access type (Hidden, Shared, Public) means, which goes beyond the schema's enum values. It also notes that sharing is a separate operation, providing useful behavioral guidance. It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action. It packs useful information—access types and a follow-up sharing step—without wasted words. Every sentence earns its place, making it appropriately concise and structurally sound.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with four parameters, two enums, and no output schema, the description covers the key points: purpose, access type meanings, and the next step for sharing. It does not explicitly mention return values or prerequisites, but given the clear schema and annotations, it is sufficiently complete for an agent to invoke the tool correctly. A score of 4 reflects the minor gap about return values while acknowledging the strong coverage of behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all four parameters described. The description adds value by defining the accessType enum values (Hidden=only owner, Shared=explicit sharing, Public=all users), which the schema only lists without meaning. This goes beyond the schema's descriptions and helps an agent understand the parameter's behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a folder for organizing Reports or Dashboards,' which is a specific verb+resource. It distinguishes from siblings like sf_create_report and sf_create_dashboard (which create actual reports/dashboards) and from sf_share_report_folder (which handles sharing). The purpose is unambiguous and differentiates from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by explaining folder access types and explicitly directs users to 'use sf_share_report_folder to grant access' after creation, which clarifies when to use that alternative. It does not explicitly say when not to use this tool or compare with creating reports/dashboards, but the intended usage is clear enough for an AI agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the description's extra context about role-based sharing and hierarchy is additive value. It explains the semantic consequences of roles without contradicting annotations. There is no mention of return values or side effects, but the annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: the first states the action, the second explains the domain concept, and the third gives a key parameter guidance. No filler or repetition. The description is front-loaded with the purpose and earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, so some return-value guidance could be useful. The description explains core hierarchy behavior and parent role placement, covering the most critical context. The absence of response details is a mild gap, but the description adequately frames the tool's operation for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 value by explaining the parentRole parameter's role in placing the role in the hierarchy, which directly ties to record visibility. It also implies the access-level parameters affect subordinate visibility, though it doesn't detail syntax. This exceeds the baseline by connecting parameters to their business meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates a Role in the Salesforce role hierarchy,' which is a specific verb-resource pairing. It clarifies the domain (role hierarchy) and distinguishes this from sibling tools like sf_create_role_hierarchy or sf_create_user_role_hierarchy by focusing on a single Role entity. The contextual statement about role-based sharing reinforces its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: when modeling a role hierarchy with record visibility implications. It explains the parentRole behavior and how to create a top-level role. However, it does not explicitly cite alternative tools or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate this is a mutating operation (readOnlyHint false), the description adds valuable behavioral context beyond them: scratch orgs are temporary, configurable, and require an authorized Dev Hub. This discloses lifecycle and authorization needs not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose statement, followed by brief context and a compact parameter list. Every sentence earns its place—no fluff or redundancy—and the structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only four optional parameters, the description adequately covers prerequisites, purpose, and parameters. It doesn't mention what happens after creation (e.g., returned org ID) or how to use the alias later, but this is not required given the annotations and simplicity. Slightly more detail on post-creation behavior would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter descriptions, so the baseline is 3. The description adds an extra detail for definitionFile ('optional, defaults to CLI default'), which clarifies behavior beyond the schema. This bump merits a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a Salesforce scratch org using the SF CLI' with a specific verb and resource. It also clarifies that scratch orgs are temporary, configurable environments for development and testing, distinguishing them from other Salesforce environment creation tools like sf_create_sandbox.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: for temporary development/testing environments, and it explicitly mentions a prerequisite: 'Requires a Dev Hub org to be authorized.' However, it does not name alternative tools or explicitly state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide the read/write/destructive profile; description adds useful behavioral context by explaining channelType options, capacity as 'maximum simultaneous work items', and that relatedObjectApiName is required for Custom type. No contradictions with annotations. Could mention permissions or side effects, but not essential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences with no redundancy: opens with the main action, then provides essential parameter details, and closes with ecosystem context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's core function, key parameters, and how Service Channels fit into the broader OmniChannel architecture. No output schema exists, so return-value details are not expected. Missing explicit prerequisites (e.g., OmniChannel setup) and edge-case error conditions, but overall adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so the description adds valuable beyond-schema meaning: capacity semantics, channelType enum values, and the requirement for relatedObjectApiName in Custom type. It does not explain channelName or label, but those are reasonably inferable from property names and schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Creates' plus resource 'OmniChannel Service Channel' and its function ('connects work items from a Salesforce object to the OmniChannel routing engine'). Clearly distinguishes from sibling tools like sf_create_routing_configuration or sf_create_presence_configuration by naming the exact resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains the role of Service Channels in the OmniChannel ecosystem ('Service Channels are referenced by Routing Configurations and Presence Configurations'), implying when to use this tool relative to related configurations. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=false and idempotentHint=true, so the tool's mutating nature is known. The description adds valuable behavioral context: it 'Builds a package.xml and deployment zip in memory' and 'Polls until complete or timeout,' plus explains the checkOnly flag avoids changes. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of four focused sentences, each with a distinct purpose: core action, in-memory packaging, validation shortcut, and production test requirement plus polling. There is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex deploy tool with 7 parameters and no output schema, the description covers the main behaviors (deploy, validate-only, runTests, polling) and operational effects. It omits explicit return-value details and scenarios like combining 'components' with 'componentsXml', but the rich schema fills those gaps. It is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by highlighting 'runTests' as required for production and explaining checkOnly as a validation-only mode. It also references the packaging process that relates to components/componentsXml, but does not over-repeat schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Deploys a set of metadata components directly to the org using the Metadata API SOAP deploy operation,' using a specific verb and resource. It clearly distinguishes this from sibling tools like sf_retrieve_metadata and sf_check_deploy_status by naming the Metadata API deploy operation and the in-memory package.xml/zip construction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides concrete usage guidance: 'Supports validate-only (checkOnly:true) for pre-deployment validation without making changes' and 'Specify runTests ... required for production.' It implies the primary use case is deploying metadata, but it does not explicitly mention alternatives or exclusions, such as when to prefer individual create tools or sf_check_deploy_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds value by stating that the retrieved configuration includes elements, activation status, and LWC settings, giving behavioral insight into what the tool returns. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the verb 'Retrieves', and every word contributes to understanding the tool. There is no fluff or repetition of schema/annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description adequately lists the key content of the retrieval (elements, activation status, LWC settings) and states the identifying parameters. It does not detail the return format or error behavior, but for a simple read-only operation with strong annotations, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for type and subType, and language has a default. The description enhances this by clarifying that the three parameters together identify the OmniScript, which adds semantic meaning about the composite key relationship beyond the individual field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieves' and names the resource 'configuration of an OmniScript' with a clear scope (elements, activation status, LWC settings). It also identifies the composite key (Type + SubType + Language), making the tool's purpose unambiguous and distinct from create/update/activate siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (to retrieve an OmniScript's configuration) and specifies the required identifiers. However, it does not explicitly mention alternatives or when not to use it, such as contrasting with sf_get_flexcard or sf_get_integration_procedure, so it misses the full 'alternatives' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context by explaining aggregate query support and the resulting field-key format (e.g., 'expr0'), which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a direct first sentence followed by a concrete aggregate query example. Every sentence earns its place; no redundant or vague content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and the special case of aggregate queries, including return format. It does not explain pagination or error behavior, but the schema covers the limit parameter, and the annotations cover safety. Adequate for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters have descriptions. The description enhances this with a full SOQL example and explains aggregate result mapping, adding meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a SOQL query against the org and returns matching records, using a specific verb and resource. It distinguishes from sibling tools like sf_get_record and sf_search_records by emphasizing raw SOQL flexibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases: reading data, checking existing records before creating, and verifying changes. This gives clear context, but it does not mention alternatives or when not to use this tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: refreshing resets the sandbox to the current production state, and the operation is asynchronous. This adds valuable context. It does not contradict the annotations (readOnlyHint=false, destructiveHint=false), though it could further detail potential data loss in the sandbox, but the reset semantics are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the core purpose. Each sentence adds necessary context: how it works, prerequisite/alternative, and async monitoring. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (async refresh) and has no output schema. The description covers the main workflow and points to monitoring via sibling tool. It could mention return behavior (e.g., whether an operation ID is returned), but overall it gives sufficient context for an agent to use the tool correctly and follow up.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions for sandboxName, licenseType, and autoActivate. The description doesn't add extra parameter-level detail, but it reinforces that sandboxName must refer to an existing sandbox. This meets the baseline but doesn't exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Refreshes an existing sandbox org by re-copying it from production via the Tooling API.' It distinguishes itself from sf_create_sandbox by specifying 'The sandbox must already exist (use sf_create_sandbox for new sandboxes).' This is 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: when to use (for existing sandboxes) and when not to use (for new sandboxes, pointing to sf_create_sandbox). It also mentions the asynchronous nature and directs users to sf_list_sandboxes for monitoring, giving clear guidance on next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations: it reads the current definition, merges changes, redeploys, automatically deactivates the card if active, and replaces field arrays entirely. While annotations indicate idempotency and non-destructiveness, the description enriches the agent's understanding of the tool's 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a distinct purpose: what the tool does, how to use it, and a critical behavioral caveat. It is front-loaded with the action and contains zero filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and lack of output schema, the description covers the essential behaviors: read-merge-redeploy, deactivation, array replacement, and partial updates. It does not describe return values or error handling, but for an update tool with strong annotations and clear sibling context, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, so the description must compensate. It explains the semantics of the arrays (fields, actions, states) by noting they are replaced entirely if provided, and implies all other parameters are optional. However, it does not explain dataSourceName, dataSourceType, label, or description beyond their names, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Updates' and clearly identifies the resource as 'OmniStudio FlexCard (OmniUiCard)'. It distinguishes from sibling tools like sf_create_flexcard, sf_get_flexcard, and sf_activate_flexcard by describing the update-and-redeploy workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Provide only the fields you want to change', which clarifies usage intent. It also names the alternative tool sf_activate_flexcard for reactivation after the automatic deactivation, providing both context and an exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, idempotent=true, destructive=false. The description adds valuable context about how the permission is consumed (formulas/Apex) and that requiredPermissions establishes dependencies. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with two short paragraphs: one for purpose/usage and one for parameters. No redundant or filler content; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with four fully documented parameters and appropriate annotations, the description is complete. It covers what the tool does, how to use it, parameter meaning, and downstream usage patterns, making it self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all four parameters, but the description adds a concrete example (fullName: 'Can_Approve_Discounts') and clarifies that requiredPermissions are a prerequisite. This enhances the schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Custom Permission and explains how it is used via formulas or Apex. This distinguishes it from sibling tools like sf_create_permission_set and sf_create_field_level_security.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use cases (feature flags, conditional UI, access gates) and notes that custom permissions are assigned via Permission Sets, which helps differentiate from related tools. However, it does not explicitly state when not to use this tool or compare alternatives directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-destructive, and idempotent operation. The description adds that the card is created in an inactive state, which is vital for lifecycle expectations. It also describes the components (data source, fields, actions, states) that affect behavior, though it does not disclose conflict or overwrite behavior, which is partially mitigated by the idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, conceptual breakdown, lifecycle note, and bulleted list of dataSourceType options. It is front-loaded with the core purpose and each section earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 9 parameters and no output schema, the description covers the most critical context: data source selection, component parts, and the inactive-creation lifecycle. It could add return-value expectations or error scenarios, but the existing guidance is sufficient for an agent familiar with FlexCards. The activation pointer and data source semantics fill the most significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides explicit mapping between dataSourceType and dataSourceName, which is not evident from the schema alone. It clarifies that SOQL expects a query string, DataRaptor an interface name, IntegrationProcedure a key, Apex a class name, and None requires no data source. This significantly enhances the schema's 78% coverage and fixes ambiguous schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates an OmniStudio FlexCard (OmUiCard metadata type)', clearly identifying the resource and the create action. It distinguishes from siblings like sf_update_flexcard and sf_activate_flexcard by specifying the create scope and noting the card is initially created in an inactive state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool by detailing the FlexCard creation context and its lifecycle. It explicitly directs activation to sf_activate_flexcard after creation, but it does not include when-not-to-use or comparisons with other creation tools. The dataSourceType options provide clear usage guidance for selecting the correct source configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-destructive, idempotent operation. The description adds useful context by labeling it 'legacy automation' and listing the types of actions it can trigger (field updates, email alerts, outbound messages, tasks), which helps an agent understand potential side effects beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, opening with a clear purpose sentence, then usage guidance, followed by a concise parameter list. It is somewhat long but every sentence carries useful information, and the parameter list is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 7 parameters and no output schema, the description covers purpose, usage, and parameter semantics thoroughly. It omits details like permission requirements or deployment behavior, but the annotations and schema cover most safety-critical aspects, making it sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds value by clarifying that 'formula or criteriaItems' are alternative ways to define the rule and by restating the triggerType options in plain language, which enhances the schema's one-line descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Creates a Workflow Rule (legacy automation)' and distinguishes it from Flows by saying it is for simple automations. It names the specific resource and action, which differentiates it from sibling tools like sf_create_flow and sf_create_validation_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a when-to-use directive: 'Use for simple automations that don't require the power of Flows.' This names an alternative (Flows) and implies a boundary for when not to use it, which is sufficient for an agent to make a correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive, idempotent, open-world operation. The description adds behavioral context by explaining that Work Types set defaults and requirements that affect work orders, and by clarifying that block times are travel/prep and cleanup time. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: a single introductory sentence explaining the purpose, followed by a tight list of key parameter explanations. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the entity's purpose and key parameter semantics, and annotations provide safety context. However, it does not mention return values or success behavior (e.g., what the API returns upon creation), nor prerequisites like requiring Field Service license or existing skills. Still, given the available schema and annotations, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers most parameters but leaves ambiguity in durationType and skillRequirements. The description explicitly states durationType values (Minutes, Hours, or Days) and defines skillRequirements as an array of { skillName, skillLevel }, adding meaning beyond the schema's 'Required Skill DeveloperNames'. It also clarifies block times with real-world context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Creates a Work Type that defines a category of field service job', using a specific verb and resource. It distinguishes itself from siblings by emphasizing the field service context and outlining what Work Types do (set default durations, block times, skill requirements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when creating a Work Type for field service jobs. It does not explicitly specify when not to use or name alternatives, but the purpose is unambiguous and the context is sufficient for typical selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotation flags (readOnlyHint=false, destructiveHint=true, idempotentHint=true). It discloses that deletes are independent per fullName, that responses must be checked for partial failures, and that dependency-order requirements exist (e.g., deleting a Bot before its children, CustomField before CustomObject). This rich behavioral detail is not present in the annotations and is crucial for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence contributes value: it states the core operation, the motivation, the independent-delete behavior, and dependency warnings. It is front-loaded with the purpose and uses clear structure. While it could be slightly more compact, it is not verbose or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema), the description is quite complete. It covers the operation, supported types, failure mode (check deleted/errors lists), and dependency constraints. It does not fully describe the response structure, but it references the key response fields, which is sufficient for an agent to infer the return format. Overall, it adequately prepares the agent for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for both parameters. The tool description adds context beyond the schema by explaining how fullNames are processed independently and how metadataType interacts with dependency rules. It also provides concrete examples (delete CustomField before CustomObject) that enrich the semantic understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Permanently deletes one or more metadata components of a given type via the Metadata API's deleteMetadata call'. It names common metadata types and explicitly contrasts with sf_deploy_metadata, which only adds/updates, clearly distinguishing this delete-oriented tool from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when metadata components need to be removed, especially those created previously by the MCP server, noting that sf_deploy_metadata does not support destructiveChanges. It also explains dependency-order prerequisites for certain types, giving practical usage guidance. It does not explicitly enumerate exclusions, but the alternatives are implied by the contrast with sf_deploy_metadata and sibling data-deletion tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description goes beyond by explaining the mechanism (FieldPermissions query object) and scope (all Profiles and Permission Sets). It doesn't detail return format or pagination, but the safety profile is covered and the added context is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a front-loaded verb ('Reads'), a clear explanation, usage guidance, and the parameter lines are brief and directly useful. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and no output schema, the description fully explains what the tool does, when to use it, and what it targets. The statement 'Reads the current field-level security grants... across all Profiles and Permission Sets' clearly implies the output. The use cases and relation to the create tool make it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions and examples for both parameters (objectName and fieldName) with 100% coverage. The description repeats the same parameter names and examples without adding new semantics, so it merely mirrors the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verb and resource: 'Reads the current field-level security grants for a field across all Profiles and Permission Sets that reference it, via the FieldPermissions query object.' This distinguishes it from sibling sf_create_field_level_security, which sets grants. The title 'Get Field Level Security (Audit)' reinforces the read-only audit purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use to audit who can currently see or edit a field before changing access, or to answer "which profiles can edit this field?".' It also identifies an alternative: 'Complements sf_create_field_level_security, which sets grants but doesn't report the current state.' This provides clear usage context and differentiation from a related tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true, and destructiveHint false. The description adds valuable context beyond these: the 6-month data retention window, the specific returned fields, and enumerated status/loginType values. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: first sentence states purpose, followed by return fields, enums, use-case bullets, and a note on data retention. Every sentence earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 adequately covers return fields and enum values. It also includes the 6-month retention limitation and typical use cases, making it sufficiently complete for a read-only query tool with good schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all five parameters. The description enriches parameter understanding by listing all possible values for status (Success, Failed, etc.) and loginType (Application, API, etc.), which the schema only gives examples for. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Queries LoginHistory' to reveal login activity, including who, from where, and success status. It lists specific return fields and enum values for status and loginType, making it distinct from other audit/history tools like get_setup_audit_trail or get_field_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a 'Useful for' list covering security monitoring, compliance auditing, and suspicious account investigation, clarifying when to use this tool. It does not explicitly name alternative tools or scenarios where it should not be used, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds context by specifying the return content (names, IDs, pipeline info) and that it lists 'all' projects in the org, without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action, and every sentence earns its place. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 strong annotations, the description fully covers what the agent needs: what it does, what it returns, and when to use it. No output schema is needed, and no additional behavioral context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description does not need to explain parameters; it adds value by describing the return fields, which is relevant since there is no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Lists all DevOps Center projects in the org') with a specific resource and scope. It distinguishes itself from sibling tools by explicitly noting it returns project names/IDs and pipeline info, and by mentioning discovery of project IDs for other DevOps Center operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use to discover project IDs needed for other DevOps Center operations.' This tells the agent when to use the tool, though it does not explicitly name alternatives or exclusion criteria, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint: false, idempotentHint: true, destructiveHint: false), the description discloses the critical behavior that the planner REPLACES any existing planner, and omitting a topic removes it from the agent. This added context is vital for safe use and goes well beyond the annotation metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and step, and each sentence adds value. The synonym list is slightly redundant but helps with keyword matching. Overall, it's efficient and well-structured, though not perfectly minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the purpose, placement in the sequence, the critical replacement behavior, and the completion criterion. With no output schema needed, the description is sufficiently complete for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all parameters have detailed descriptions in the schema. The tool description primarily reiterates the same information (e.g., complete list of topics, exact agentName match) without adding new parameter-level meaning beyond what the schema already provides. Therefore, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a GenAiPlanner that connects an Agentforce Agent to its Topics, and identifies it as STEP 4 (FINAL) of the setup sequence. It also lists synonyms to reinforce its role, distinguishing it from sibling steps like sf_create_agent or sf_create_agent_topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: as the final step after topics/actions are created, and warns that without it the agent cannot route any request. Provides clear guidance for modifying an existing agent (include all previous topic names). The instruction to only report completion after this step succeeds is a strong usage directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive behavior. The description adds valuable context about the return value (complete bundle file contents) and the optional Apex controller. It could elaborate on filesystem side effects, but given the strong annotation coverage, this is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a distinct purpose: purpose, return contents, parameter guidance, and sibling differentiation. It is front-loaded with the core action and contains no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description explains the return format and usage context sufficiently. It could briefly clarify whether files are written to disk or just returned as content, but the explicit return statement largely covers this. Overall, it is well-rounded and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description goes further by highlighting key parameters (interfaces, attributes, controller) and providing a concrete example ('force:appHostable for App Builder'), which helps the agent map user intent to schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Generates' and identifies the exact resource: 'An Aura (Lightning Component Framework) component scaffold'. It clearly distinguishes from sibling tools by explicitly recommending sf_create_lwc for new development and positioning this tool for legacy migration scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use sf_create_lwc for new development — Aura is for legacy migration scenarios.' It names the alternative tool and the appropriate context for using this one, satisfying the when-to-use requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing key behavioral traits: the script is created inactive, the fullName is derived as Type_SubType_Language, and isLwcEnabled deploys as a Lightning Web Component. It also sets expectations that complex configuration requires the designer. These details add significant transparency about side effects and output naming, even though annotations already indicate mutation and open-world behavior. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but every sentence carries useful information. It opens with a crisp summary, then adds naming, inactive status, designer guidance, flag explanations, and a next-step pointer. No redundant or filler content; the structure is logical and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description covers most context: creation state, naming, flags, and activation next step. However, it does not describe what the tool returns (e.g., an ID or fullName) or potential errors like duplicate fullName. The naming convention partially compensates by allowing users to infer the identifier, but an explicit return value mention would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 78% schema description coverage, the schema already documents most parameters. The description adds extra meaning by explaining the fullName derivation from type/subType/language and clarifying the practical effect of isLwcEnabled and isOmniScriptEmbeddable. This supplements the schema's descriptions, particularly around naming, which is not explicit in the schema. A score of 4 reflects the added value beyond the high baseline coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Creates an OmniStudio OmniScript — a guided interaction flow for collecting data or performing processes.' It uses a specific verb and resource, and distinguishes itself from siblings by mentioning the script is created inactive and by directing users to sf_activate_omniscript for the next step. This makes the purpose unambiguous and differentiates it from related tools like update/get/activate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear lifecycle guidance: it notes that complex element configuration should be finalized in the OmniStudio Designer after creation and explicitly points to sf_activate_omniscript for activation. However, it does not explicitly contrast with sf_update_omniscript or sf_get_omniscript, so the 'when not to use' aspect is implied rather than stated. Still, the activation pointer and designer note give strong contextual usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds beyond that by specifying the status change to Draft, the effect on triggering, and explicitly stating that deactivation is not deletion. This is meaningful behavioral context, though it does not mention any prerequisites or side effects like whether a flow must have an active version.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each with a distinct purpose: main action and effect, alternative tool, and non-destructive note. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with annotations and no output schema, the description covers the core behavior, the consequence (stops triggering), the relationship to activation, and the non-deletion aspect. It doesn't explain what happens if there is no active version or how to handle errors, but for the simplicity of the operation, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% parameter coverage with 'flowApiName' described as 'Flow API name to deactivate'. The description adds value by clarifying that the operation targets the 'currently active version', which explains what the API name refers to in the context of deactivation. It also notes the use of the Tooling API, giving extra semantic context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Deactivates the currently active version of a Flow via the Tooling API, setting its status to Draft.' It uses a specific verb and resource, and explicitly distinguishes from the sibling sf_activate_flow, which is mentioned as the counterpart for re-activation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'This stops the flow from being triggered.' It also names the alternative tool explicitly ('Use sf_activate_flow to re-activate a specific version') and clarifies a common misconception with 'Note: deactivating a flow does not delete it.' This satisfies the when-to-use and alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral nuance beyond the annotations. It discloses that emails are sent from the running user's address, respect org deliverability settings, and that saveAsActivity defaults to true (creating an activity record). It also warns about daily email limits, which are not surfaced in the annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a concise opening sentence, a bulleted list of key parameters, and a note about limits. Every sentence earns its place, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core behavior, parameter semantics, and important limitations (deliverability, email limits, mass email alternative). It doesn't describe the return value, but since there is no output schema and this is a side-effectful action, that omission is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage, but the description clarifies semantics: htmlBody takes precedence over body, templateName replaces body text, and whatId/whoId link the email to records/person records. This adds valuable context beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Sends an email from Salesforce using the emailSimple invocable action.' This specifies the verb (send), resource (email via Salesforce), and mechanism (emailSimple invocable action), distinguishing it from sibling tools like sf_create_email_template or sf_create_email_alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-not guidance: 'Mass emails should use list email features instead.' This implies the tool is for individual/transactional emails. It doesn't name a specific alternative tool, but the direction is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key side effect: activating a new version automatically deactivates the previous active version. This goes beyond the annotations (which only indicate it's a write and idempotent) and provides important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the purpose and end with a related-tool pointer. Every sentence earns its place, with no repetition or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with annotations and no output schema, the description covers the action, side effect, and prerequisite discovery step. An agent has sufficient context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with 100% description coverage, including the default behavior of versionNumber. The description's mention of 'or the latest version' reinforces the schema but adds no new semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool activates a specific Flow version via the Tooling API, naming the action and resource. It also notes the one-active-version constraint, distinguishing it from related tools like sf_deactivate_flow or sf_list_flow_versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to first run sf_list_flow_versions to discover available versions, providing a clear workflow and prerequisite. It also explains the consequence of activating (auto-deactivating the previous version), which helps agents decide when 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, idempotentHint=true), the description adds behavioral context: it reveals that agentName and topicName are informational only and NOT written to the action XML, and that the referenced flow/class must already exist. This adds value by clarifying side effects and preconditions, though it doesn't detail failure modes or idempotency behavior (which the annotation already covers).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though dense, every sentence serves a purpose. The structure uses clear inline headings ('IMPORTANT by type', 'After ALL actions') and front-loads the primary action. It balances detail with readability for a complex 8-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, multi-step tool with no output schema, the description is remarkably complete. It covers the overall agent setup sequence, per-type prerequisites, parameter nuances, and next steps. It doesn't need to explain return values because no output schema exists and the description focuses on the operation's role in the larger workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 reinforces schema details (e.g., 'reference' is the exact API name) and adds usage-level semantics like remembering actionName for the subsequent sf_create_agent_topic call. It goes slightly beyond the schema by explaining the sequence, but much of the parameter meaning is already in the schema, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Creates an Agentforce Action (GenAiFunction)' and immediately positions it as 'step 2 of the agent setup sequence,' distinguishing it from sibling tools like sf_create_agent_topic and sf_create_agent_planner. This clearly establishes what the tool does and where it fits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided on when to call ('once per capability'), prerequisites for each type (e.g., Flow must be Active AutoLaunchedFlow, ApexClass must have @InvocableMethod), and the correct subsequent calls (sf_create_agent_topic then sf_create_agent_planner). It even warns not to stop between steps, giving clear sequential usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a critical failure mode (omitting actions results in a silently non-functional topic), clarifies that agentName is informational only, and indicates that the actual wiring happens in a later step. This adds meaningful context beyond annotations like idempotentHint and readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are front-loaded with the primary purpose, followed by critical warnings and sequence instructions. Every sentence earns its place with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the sequence position, prerequisites, critical parameter behavior, and the required next step, making it complete for standalone use even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed parameter descriptions, including the CRITICAL warning about actions and the informational nature of agentName. The tool description reiterates these points but does not add new parameter-level meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Creates a Topic (GenAiPlugin) for an Agentforce Agent' and identifies itself as 'step 3 of the agent setup sequence,' clearly distinguishing it from sibling tools like sf_create_agent_action and sf_create_agent_planner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit sequencing: 'Call this AFTER all actions have been created with sf_create_agent_action' and requires calling sf_create_agent_planner immediately after. It also warns 'Do not stop between steps,' giving strong workflow guidance and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation, open-world behavior, and idempotency. The description adds valuable context by explaining the bot is created with an ML domain and by listing post-creation steps (train, activate, connect). It does not cover potential side effects like name collisions, but the annotations reduce the burden, and the added lifecycle guidance is useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a high-level summary, a 'Note' for alternatives, a bulleted list of use cases, a dialog-definition breakdown, and a numbered post-creation workflow. Every section serves a clear purpose, and the length is justified given the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description is thorough: it covers what metadata types are created, how dialogs are configured, the ML domain behavior, and the necessary manual follow-up steps (train, activate, connect). This gives the agent enough context to use the tool and set expectations, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptive parameter names and comments. The description goes beyond by explaining the purpose of each dialog field ('utterances: training phrases that trigger this dialog', 'messages: bot responses') and clarifying dialog types (Main, System, Rule). This enriches the schema with semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Creates a classic Einstein Bot (Bot + BotVersion metadata types) with one or more conversation dialogs.' It clearly distinguishes from the sibling sf_create_agent by contrasting classic bots with AI-first agents, leaving no ambiguity about 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use classic Einstein Bots ('Structured FAQ automation', 'Simple data collection workflows', 'Channels that don't support Agentforce') and directly points to sf_create_agent as the alternative for AI-first agents. This is textbook usage guidance with clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description adds critical context: deletion is permanent, goes to Recycle Bin for supporting objects, and can be undeleted within 15 days. This adds value beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main function, and every sentence earns its place—core operation, input guidance, and bulk alternative. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool, the description covers behavior, inputs, and alternatives. Annotations and schema handle safety and parameter details, so no gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 repeats the parameter requirements (object API name, 15 or 18 character record ID) but adds no new semantic meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Deletes a single SObject record by record ID via the Salesforce REST API.' It clearly distinguishes from bulk deletion tools by explicitly saying 'single' and naming the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and alternative: 'For bulk deletions (100+ records), use sf_bulk_import_records with operation='delete'.' It also clarifies the required inputs (object API name and record ID).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context by specifying return contents ('class body, API version, and status') and the exact-name matching behavior, which is useful beyond the structured annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, then usage context, then a contrasting sibling reference. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, no output schema), the description covers what it does, when to use it, and what it returns. It is fully sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, but the description adds semantics: 'exact name' and 'existing Apex class' clarify required matching and preconditions. This enhances the schema's minimal 'Apex class name to retrieve'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Retrieves') and resource ('full source code of an existing Apex class by exact name, via the Tooling API'), and explicitly differentiates from sibling sf_create_apex_class, which writes/deploys code. This leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'Use before modifying a class (to see current logic), when debugging, or when a user asks...' and names the alternative tool to avoid confusion. It clearly states this tool only reads, making the usage context unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: it specifies the return fields (version number, status, description, creation date), clarifies the meaning of 'deactivated' as 'Obsolete', and mentions the Tooling API as the underlying mechanism. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all directly useful. Front-loaded with the main action and scope, then return details, then parameter guidance. No filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with rich annotations and full schema coverage, the description is complete. It covers the API type, return fields, optional filtering, and parameter usage. No output schema exists, so the description responsibly explains the return content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already well-described. The description adds slight semantic value by mapping 'deactivated' to the 'Obsolete' status and reinforcing the omit-to-list-all behavior for flowApiName, but it does not dramatically expand beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Lists all versions of a specific Flow, or all Flows in the org, via the Tooling API.' It clearly distinguishes this listing tool from sibling mutation tools like sf_activate_flow or sf_deactivate_flow, and from sf_get_flow_errors which targets errors, not versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear usage context is provided: listing all versions of one flow or all flows in the org, with optional filtering to exclude deactivated versions. However, there is no explicit mention of when NOT to use this tool or direct comparison to alternative sibling tools, so it misses the top score by a small margin.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-destructive, but the description adds valuable behavioral context: it returns data from the SandboxInfo Tooling API object, includes specific fields (status, license type, dates), and notes a production-org requirement. This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences, each serving a purpose—what it lists, technical source, and when to use it. No redundant information, and it is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is complete. It covers functionality, output content, use case, and an important precondition (production org). Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to document. The description appropriately mentions the return fields, and the schema is trivially covered. Baseline for 0-param tools is 4, and no additional parameter info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists') and the specific resource ('all sandbox orgs associated with the production org'), and it enumerates the included fields (status, license type, dates). This distinguishes it from sibling tools like sf_create_sandbox and sf_refresh_sandbox by focusing on read-only listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to monitor sandbox creation and refresh status,' indicating a clear use case. It also provides a constraint ('Must be called from the production org') and implicitly contrasts with create/refresh siblings, though it does not name alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: the tool on first call probes org capability and fails without creating an orphaned shell, re-running updates the existing agent, and creating the shell alone produces a non-functional agent. This complements idempotentHint and readOnlyHint without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence and the long paragraph is dense with necessary workflow, probe, and idempotency details. It is appropriately sized for a complex 5-step tool, though the wall-of-text structure could be formatted more scannably.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description covers the full lifecycle: prerequisites, exact sequence, failure behavior ('fails with no shell created'), when to skip the probe, and the plannerName re-link pattern. It is complete enough for an agent to invoke and sequence this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 beyond-schema meaning for agentName ('Used in all subsequent calls'), plannerName ('normally omitted on the first call... call this tool again'), and skipActionCapabilityCheck (topics-only condition). This moves it above baseline, though not every parameter receives additional enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
First sentence clearly states it 'Creates an Agentforce Agent (Einstein Copilot) shell in Salesforce' — a specific verb+resource. It distinguishes itself from sibling tools by labeling itself 'STEP 1 OF A 5-STEP SEQUENCE' and naming sf_create_agent_action, sf_create_agent_topic, and sf_create_agent_planner as the subsequent tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit numbered sequence with exact order, including prerequisite step 0 (sf_create_flow/sf_create_apex_class) and the rule to continue through all steps autonomously. It also specifies when to use skipActionCapabilityCheck, giving clear when/why guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond annotations by disclosing that the tool deploys 'all 3 underlying metadata records' in one call, revealing atomicity. It also warns about an important limitation: 'the Consumer Key/Secret ... can still only be viewed once in Setup ... no Salesforce API exposes it.' This is critical behavioral context not conveyed by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but front-loaded with the core purpose and followed by a clear comparison, deployment detail, scope guidance, and a crucial limitation note. No sentence is redundant; each adds meaningful context. It earns a 4 rather than 5 because it is on the longer side, though every part contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex creation tool with no output schema, so the description carries the burden of explaining what happens and what is needed after creation. It covers the created record types, the key configuration options (client credentials flow, scopes), and the consumer secret retrieval limitation. This is sufficient for a model to invoke and reason about the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 highlighting which parameters matter most: 'enableClientCredentialsFlow + clientCredentialsFlowUser' are called out as fully configurable for ECA, and the 'Chatbot'/'SFApiPlatform' scopes are connected to a specific use case. This contextual grouping helps a model reason about parameter choices beyond the individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Creates an External Client App (ECA), Salesforce's newer replacement for Connected Apps, for OAuth authentication and server-to-server integrations.' It further distinguishes itself from the sibling sf_create_connected_app by explicitly recommending this tool over the alternative. This is a clear, non-tautological purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Prefer this over sf_create_connected_app' with a concrete reason (full configurability of Client Credentials Flow including the run-as user via this tool, unlike the Setup-UI-only configuration on Connected Apps). Additionally, scope selection advice is given for Agent API usage: 'Use Chatbot and/or SFApiPlatform scopes.' This tells a model exactly when to use this tool and what parameters to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, openWorld), the description discloses important behavioral traits: it uses the REST Describe API, can return only fields with fieldsOnly, and includes a retry mechanism when waitForFields is used due to Salesforce-side schema cache lag. This is substantive context not available from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description is concise and front-loaded, but the parameter explanations become somewhat lengthy, especially waitForFields. However, each sentence provides valuable context and none is redundant, so it remains well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description fully covers what the response contains, when to use it, and parameter-specific edge cases. It also explains the fieldsOnly and waitForFields behaviors, making the tool self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already covers all parameters (100%), the description adds meaningful context: fieldsOnly's performance rationale, waitForFields detailed explanation about Salesforce cache lag and retry behavior, and timeoutSeconds default/max. This goes beyond schema descriptions, though the schema itself also carries clear descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Retrieves schema metadata for a Salesforce object via the REST Describe API' and enumerates the specific data returned (fields, child relationships, record type info). This is a specific verb+resource that distinguishes it from sibling tools like sf_get_field_permissions or sf_query_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises when to use the tool: 'Call this before querying or creating records on an unfamiliar object, or when a user asks what fields exist on an object.' This provides clear contextual guidance and differentiates from alternatives without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant behavioral context beyond annotations: it states the tool returns metadata but not content, requires an active trace flag for logs to appear, and lists the specific metadata fields (ID, start time, duration, status, operation). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose. The parameter list is concise but repeats some schema text. The additional sentences about requiring a trace flag and pointing to sf_get_debug_log_body are valuable and not excessive. Slight redundancy in parameter descriptions prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by listing what metadata fields are returned and explicitly excluding log content. It also covers the prerequisite (trace flag) and the relationship to sibling tools (sf_enable_debug_logs and sf_get_debug_log_body). This makes the tool fully understandable in its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters at 100% coverage, so the baseline is 3. The description adds extra value by providing an example for operation ('execute_anonymous_apex') and clarifying default/max limits for limit. While largely redundant, the examples and contextual notes enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Lists recent Apex debug logs (ApexLog records) via the Tooling API,' clearly stating the verb, resource, and API. It distinguishes itself from sibling tools by explicitly mentioning sf_get_debug_log_body for log content and sf_enable_debug_logs for enabling logging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use sf_enable_debug_logs first if no logs are showing up' and explains the trace flag prerequisite. It also directs users to sf_get_debug_log_body when full log content is needed, clearly defining this tool's scope versus its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description discloses the crucial constraint that only metadata is updated, not elements/steps, and provides the fullName construction rule (procedureName_subType). It also explains the deactivation/reactivation workflow, which is non-obvious behavioral context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose in the first sentence, the identifier rule in the second, and a clear workflow/alternative in the following sentences. Every sentence adds value; there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, four parameters, and no output schema, the description covers the essential context: what fields are updatable, how the record is identified, what is explicitly out of scope (element/step changes), and the activation workflow. This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, but the description compensates for most parameters: procedureName and subType are explained via the fullName = procedureName_subType equation, and isActive is clarified by the explicit 'Set isActive: false to deactivate' instruction. However, the exact meaning or allowable values of subType are not fully defined, leaving some ambiguity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Updates an existing Integration Procedure's metadata') and explicitly identifies the resource and the fields affected (description, active status). It also distinguishes itself from related sibling tools by defining the identifier scheme (procedureName + subType, fullName = procedureName_subType) and by referencing sf_activate_integration_procedure for activation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance: it says to use the OmniStudio Integration Procedure Designer for element/step changes, and prescribes a workflow involving setting isActive to false, making changes, then calling sf_activate_integration_procedure. This clearly differentiates from update-only metadata changes and from activation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses a key side-effect beyond the annotations: the script will be deactivated if currently active, and tells the agent how to recover. This is important behavioral context not captured by readOnlyHint, destructiveHint, or idempotentHint, and does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one clear sentence for purpose, one note for critical caveats and alternatives. Every sentence adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the six parameters, annotations, and absence of an output schema, the description provides everything needed for safe invocation: identity key, updatable properties, scope limitation, destructive side-effect warning, and reactivation path. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, but the description compensates by mapping all parameters: type, subType, and language are identifiers, while description, 'LWC mode', and 'embeddable flag' correspond to the optional property parameters. This gives the agent full semantic understanding without relying on sparse schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Updates') and names the exact resource ('existing OmniScript's metadata properties') plus the property fields and identifier fields. It also distinguishes this tool from element/step editing by stating it updates only the container metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-not guidance ('element/step editing is best done in the OmniScript Designer') and names the alternative for reactivation ('reactivate with sf_activate_omniscript'). This clearly directs the agent to appropriate use and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![salesforce-metadata-mcp MCP server](https://glama.ai/mcp/servers/semwalajay83-sem/salesforce-metadata-mcp/badges/card.svg)](https://glama.ai/mcp/servers/semwalajay83-sem/salesforce-metadata-mcp)

Score Badge

Copy to your README.md:

[![salesforce-metadata-mcp MCP server](https://glama.ai/mcp/servers/semwalajay83-sem/salesforce-metadata-mcp/badges/score.svg)](https://glama.ai/mcp/servers/semwalajay83-sem/salesforce-metadata-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/semwalajay83-sem/salesforce-metadata-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server