Salesforce MCP Pro

by adamcmyhre

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear, distinct resource-action pairs, but some overlap exists: sf_execute_apex_cursor_query and sf_build_apex_cursor_query both handle Apex cursor logic, and ui_action is somewhat vague. Despite the large count, descriptions generally disambiguate well.
Naming Consistency4/5
The sf_ prefix with verb_noun pattern is consistent (sf_list_orgs, sf_create_records), and ui_/git_ prefixes also follow a similar pattern. Minor inconsistency like sf_agent_preview_sessions (noun instead of verb) and sf_tooling_list_objects vs sf_list_metadata slightly deviate but overall naming is predictable.
Tool Count2/5
72 tools is excessive, far beyond the typical well-scoped range. While the server aims to be comprehensive for Salesforce, the sheer number creates cognitive overload and makes tool selection harder, even if each tool individually serves a purpose.
Completeness4/5
The tool surface is extensive, covering queries, CRUD, metadata deploy/retrieve, Apex execution, agents, tests, permission management, UI automation, and git workflows. Minor gaps exist (e.g., no list permission sets tool) but most core Salesforce development workflows are supported.
Average 2.9/5 across 72 of 72 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it offers nothing. It does not mention side effects, waiting/retry behavior, error handling, state changes, or return values, leaving the invocation behavior completely opaque.
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 description is a single sentence, but it suffers from under-specification rather than being efficiently concise. The words provide minimal information and do not justify their presence; more content is needed to be minimally useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has five parameters, an enum of actions, and no output schema, yet the description does not cover the range of actions, value handling, session context, or expected results. It is severely incomplete 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only mentions 'selector' generically and does not explain the 'action' enum, the optional 'value' parameter, 'timeoutMs', 'sessionId', or how they interact. It adds no meaning beyond the raw schema fields.
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 'Perform a direct UI action on a selector' essentially restates the tool name (ui_action) with generic wording. It does not enumerate the specific actions (click, fill, type, press, etc.) available in the schema, nor does it distinguish the tool from sibling UI operations like ui_navigate or ui_extract.
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?
There is no guidance on when to use this tool versus alternatives such as ui_navigate, ui_extract, or ui_run_flow. The description provides no context about suitable scenarios, restrictions, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it does not. It gives no information about side effects, return values, session lifetime, or required inputs. The single sentence adds no transparency beyond the bare action.
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?
While the description is brief, it is under-specified for a tool with 9 parameters. The single sentence lacks necessary detail and structure, making it more of an under-specification than a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 optional parameters, no output schema, and no annotations, but the description offers no explanation of how to use it, what the parameters mean, or how it relates to sibling preview tools. It is fundamentally incomplete.
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 0%, and the description does not mention any of the 9 parameters. It provides no meaning beyond the schema's bare type definitions, thus fails to compensate for the lack of 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 ('Start') and resource ('programmatic Agentforce preview session'), which distinguishes it from sibling tools like preview_end and preview_send. It is specific enough to convey the core purpose, though it does not elaborate on what a preview session entails.
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?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of any related tools. The description simply states what it does without providing context for choosing 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?
With no annotations, the description carries the full burden. It mentions execution via anonymous Apex, which implies running code in the org, but does not disclose whether the operation is read-only, permission requirements, Apex governor limits, or what the return value contains. This is a significant gap for a tool that executes code.
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 description is a single sentence, but it is under-specified for a tool with 16 parameters. While it avoids fluff, it fails to provide essential context, making it more of a one-line summary than a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (16 params, no annotations, no output schema), the description is severely incomplete. It does not explain what a 'cursor query' is, how pagination works, what the execution returns, or any prerequisites. This is not enough to guide correct invocation.
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 input schema has 16 parameters and 0% description coverage. The description provides no meaningful explanation of any parameter (e.g., soqlQuery, objectName, whereClause, pagination controls). This leaves the agent completely in the dark about parameter 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 states a clear compound action: building Apex cursor query code and executing it via anonymous Apex. It distinguishes from related siblings like sf_build_apex_cursor_query (likely only builds) and sf_execute_anonymous_apex (executes arbitrary code), though it doesn't explicitly mention 'cursor' pagination specifics.
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 when-to-use guidance is provided. The phrase 'in one step' hints at a combined operation but does not explain when to choose this over alternatives like sf_execute_anonymous_apex or sf_query_org_paginated.
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?
With no annotations, the description must carry the entire burden of behavioral disclosure. It only says 'Generate a ... definition file,' but does not explain side effects such as file creation, overwriting, or deployment. Parameters like 'confirm', 'overwrite', and 'deployAfterGenerate' hint at potentially destructive or confirmation-requiring actions, yet the description stays silent on these behaviors.
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 description is a single 8-word sentence, which is brief but not appropriately sized for a tool with 13 parameters and no other documentation. It is under-specified, sacrificing clarity and guidance for brevity. Key information is omitted, making the tool harder to use correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 params, no output schema, no annotations), the description is grossly incomplete. It fails to explain what 'baseline' means, how the flow definition is generated, what parameters control the output, or any prerequisites. A tool with this many options needs significantly more context to be usable.
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 0%, and the description provides no parameter details. With 13 parameters, only one of which is required, the agent has no explanation of what 'label', 'processType', 'deployWait', 'ignoreConflicts', etc., mean or how they relate to generating a flow definition. The description adds zero semantic value beyond the raw 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 states a specific action ('Generate') and resource ('Salesforce Flow metadata definition file'), which clearly identifies the tool's purpose. It distinguishes from siblings like sf_generate_lwc_component by naming Flow metadata specifically. However, the term 'baseline' is ambiguous, leaving uncertainty about whether this is a template, a default skeleton, or something else.
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?
There is no guidance on when to use this tool versus alternatives. Sibling tools like sf_deploy_metadata and sf_retrieve_metadata exist, and the description does not clarify whether this tool is a prerequisite, alternative, or complementary. The presence of deployment-related parameters (e.g., 'deployAfterGenerate') implies integration with deployment workflows, but no context is provided.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and library, without disclosing potential side effects, confirmation requirements, permissions, or record handling behavior.
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 description is a single sentence, which is concise, but it is under-specified for a tool with 5 parameters. It omits essential details, making it too terse to be considered well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is deeply incomplete. It fails to explain return values, errors, required parameters, or any operational context, making it inadequate for an agent to use correctly.
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 0%, meaning the description must compensate by explaining parameters, but it does not. None of the 5 parameters (objectName, records, confirm, directory, targetOrg) are described, providing zero added meaning beyond the schema's field names.
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 ('Update') and the resource ('records in a Salesforce object'), identifying the core function. However, it does not distinguish from sibling tools like sf_upsert_records or sf_create_records, so it is slightly less differentiated than a top-tier example.
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. The description does not mention prerequisites, target organization, or context for updates, leaving the agent without any selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits, but it merely restates the operation name. It fails to mention that this tool mutates Salesforce data, may require confirmation (implied by the 'confirm' parameter), depends on external ID lookup, or may have partial failure modes. The description adds essentially no behavioral context beyond what the tool name already implies.
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 description is a single sentence that is concise in word count, but it is under-specified rather than appropriately sized. For a tool with six parameters and no annotations, a one-line description without structure or additional context is not sufficient. It lacks front-loaded details about inputs, side effects, or usage scenarios.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an upsert operation (including external ID handling, confirmation, target org selection), and the absence of an output schema, annotations, and parameter descriptions, the description is severely incomplete. It provides no information on return values, error handling, matching behavior, or any prerequisites, making it inadequate for reliable tool invocation.
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 says nothing about any of the six parameters (objectName, externalIdField, records, confirm, directory, targetOrg), and the schema provides no descriptions (0% schema coverage). Thus the description does not compensate for the complete lack of parameter documentation, leaving the agent to guess the meaning and format of critical inputs like externalIdField and confirm.
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 'Upsert records in a Salesforce object' uses a specific verb ('upsert') and resource ('Salesforce object'), clearly distinguishing it from siblings like create, update, delete, and query. The term 'upsert' precisely conveys the create-or-update semantics without ambiguity.
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 offers no guidance on when to use this tool versus alternatives such as sf_create_records or sf_update_records. It does not mention that upsert is appropriate when an external ID field is available, nor any exclusions or prerequisites. This absence of context leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action of executing anonymous Apex and does not disclose potential side effects, required permissions, or whether it can modify data. With no annotations provided, the description carries the full burden of behavioral transparency and fails to address any of these aspects.
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 concise at one sentence, but it is under-specified for the complexity of the tool. It lacks necessary detail, making it insufficiently informative despite being brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is an arbitrary code execution tool with no output schema and no annotations, the description is far from complete. It does not mention return behavior, error handling, or usage context, leaving the agent without critical information.
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 schema lists four parameters (confirm, apexCode, directory, targetOrg) with no descriptions, and the tool description does not explain any of them. The description mentions the target org but doesn't clarify the meaning of confirm or directory, so it fails to compensate for the 0% schema 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 uses a specific verb ('Execute') with a specific resource ('anonymous Apex') and mentions the target org, clearly distinguishing it from sibling tools like sf_execute_named_query and sf_query_org.
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?
There is no guidance on when to use this tool versus alternatives such as sf_execute_named_query or sf_schedule_apex_job. The description simply states the action without any contextual usage advice.
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does not state whether the operation is read-only, whether authentication is required, what the return format is, or any limitations. The phrase 'for discovery' only implies a non-destructive intent, but no concrete traits are disclosed.
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 a single, grammatically clean sentence with no redundant words, but it omits essential details. While it is efficient, it under-specifies the tool's behavior and parameters, 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.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, one required, and no output schema, yet the description only covers the metadata type concept. It lacks information about parameter semantics, output shape, error handling, or any usage context, making it insufficient 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for any of the five parameters (0% coverage), and the description only clarifies that 'metadataType' is the filter by type. The roles of folder, directory, targetOrg, and apiVersion are unexplained, leaving the agent unable to correctly populate these fields.
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 'List' and defines the resource as 'metadata components,' filtered 'by metadata type,' which clearly indicates a discovery action. However, it does not distinguish itself from sibling tools like sf_retrieve_metadata or sf_describe_object.
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 phrase 'for discovery' hints at an exploratory use case, but the description provides no explicit guidance on when to use this tool versus alternatives such as sf_retrieve_metadata or sf_describe_object. There are no exclusions or alternative recommendations, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Install a package version' without revealing side effects, required permissions, whether it prompts for confirmation (despite a 'confirm' parameter), or any mutation of the target org. This is a significant omission.
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 a single, front-loaded sentence with no fluff, which is concise. However, it is so brief that it borders on under-specification, making it less useful for a complex tool. It is efficient in word count but lacks essential detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, a mutation operation, no output schema, and no annotations), this description is severely incomplete. It omits return values, side effects, prerequisites, and parameter meaning, failing to provide sufficient context 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 11 parameters. It does not explain any parameter such as 'package', 'wait', 'noPrompt', or 'upgradeType', leaving agents to infer from names alone. The description adds no semantic 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 states a specific verb 'Install' and a specific resource 'package version' in a 'target org', making the tool's purpose clear. It distinguishes itself from siblings like sf_package_create and sf_package_list by indicating an installation rather than creation or listing.
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 vs. alternatives. It does not mention scenarios, prerequisites, or exclude other deployment tools, leaving the agent without clear selection criteria from the description alone.
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?
With no annotations, the description must carry this burden, but it only states the action. It does not disclose whether the query returns results, how it handles errors, rate limits, or side effects. It implies a read-only operation but does not confirm or provide additional 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It does not provide enough information for a tool with three parameters and no supportive schema descriptions. It is not an 'appropriately sized' description because it omits essential usage and parameter context.
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 complexity (3 params, no annotations, no output schema), the description is incomplete. It does not explain what the tool returns, how to specify parameters, or when to use it. A one-line description is insufficient for this tool's context.
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 0%, and the description offers no explanation of the parameters (query, directory, targetOrg). The description adds no value beyond the schema, which itself has no descriptions, so the agent is left without meaning for each parameter.
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: 'Run a SOQL query against a Salesforce org.' It identifies the specific resource (Salesforce org) and the operation (SOQL query). However, it does not distinguish this from sibling tools like sf_query_org_paginated or sf_search_org, which also involve querying.
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 when to prefer paginated queries, search, or named queries, nor any prerequisites or contexts. The description simply states the action without usage direction.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'Run Apex tests' without mentioning whether execution is synchronous, what outputs are produced, or any side effects, which is insufficient for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded and easy to parse. However, its brevity causes under-specification, making it less effective than a concise description that includes key context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is far too minimal. It does not explain test selection mechanics, coverage options, or execution behavior, making it inadequate 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have 0% schema description coverage and the description adds no parameter details. It does not clarify the role of tests, suites, targetOrg, wait, or codeCoverage, leaving the agent without essential parameter 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 uses a specific verb 'Run' and clearly identifies the resource as 'Apex tests' with a Salesforce org scope. It does not distinguish from the sibling tool sf_run_apex_test_suite, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool vs alternatives like sf_run_apex_test_suite or sf_execute_anonymous_apex. The description merely states the action without contextual triggers or exclusions.
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?
With no annotations provided, the description must fully disclose the tool's behavior. It only states 'Start a Playwright browser session' but does not mention side effects (e.g., launching a browser, consuming resources), whether it requires a base URL or specific configuration, or what the session represents. This lack of detail leaves the agent without critical 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording, earning credit for brevity. However, it is under-specified for a tool with 5 parameters and no annotations, making the brevity a shortcoming rather than a quality. It communicates the core action but omits essential details, so it is acceptable but not well-structured.
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 5 optional parameters, no annotations, and no output schema, the description is insufficient. It does not explain what the tool returns (e.g., a session handle), how the parameters affect behavior, or any setup requirements. This is a critical gap for an agent attempting to invoke the tool correctly, making the description incomplete.
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 0% and the description makes no mention of any parameters (baseUrl, headless, slowMoMs, viewportWidth, viewportHeight). Since the description is solely responsible for explaining parameter meaning, its complete omission fails to add value beyond the raw schema field names, leaving the agent without guidance on parameter values or relationships.
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 the specific verb 'Start' with the resource 'Playwright browser session', clearly indicating the tool's action. It distinguishes itself from sibling UI tools like ui_session_stop and ui_navigate, which operate on an existing session. However, it could be slightly more specific about the session's scope or purpose beyond generic 'UI automation'.
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?
There is no guidance on when to use this tool versus alternatives. It states 'for UI automation' but does not mention prerequisites (e.g., prior session state), exclusions, or when to prefer sibling tools like ui_navigate or ui_action. The description leaves the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It gives zero behavioral information: no mention of required permissions, side effects, confirmation prompts, or response behavior. The agent cannot anticipate consequences.
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 single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose, though it omits much else; brevity is a strength here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with no annotations and no output schema, the description is far too sparse. It lacks parameter semantics, usage context, and behavioral details, leaving substantial gaps for an agent to safely invoke the 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 schema has 6 parameters with 0% description coverage, but the description mentions none of them. It does not explain the meaning of groupId, message, title, confirm, directory, or targetOrg, so the agent must guess or rely on parameter names 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 the verb 'post', the resource 'Chatter feed item', and the target 'collaboration group', which precisely distinguishes it from sibling tools like sf_chatter_post_to_record. It 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 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 vs alternatives, prerequisites, or context. The description only states the basic action without any exclusions or alternative references, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention side effects on the browser/session, whether confirmation is required, what the flow execution does, or what success/failure looks like. This is essentially no behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero wasted words, clearly stating the action and resource. However, its brevity leaves out crucial details, though this is accounted for in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, a nested variables object, no output schema, and no annotations, the one-sentence description is completely inadequate. The agent cannot determine how to set confirm, sessionId, or variables, or what the tool returns, making correct invocation unlikely without external knowledge.
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 0%, and the description does not explain any parameter. 'Named' only implies flowName; confirm, sessionId, and variables are entirely unexplained, leaving the agent without guidance for constructing a valid invocation.
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 'Run', names the resource type 'UI flow', and locates it in 'ui-definitions/flows.json', clearly distinguishing it from sibling tools like ui_navigate, ui_action, and sf_generate_flow_definition.
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 like ui_navigate or ui_action, nor are prerequisites such as an active session mentioned. The description only states what the tool does, not when to choose 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?
With no annotations, the description carries the burden but only states it 'builds templates', implying a code-generation action with no side effects. It does not disclose return format, whether it makes API calls, or any limitations. Lacks transparency about what the agent should expect when invoking it.
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 single, front-loaded sentence with no wasted words. It is appropriately concise for the high-level purpose, though its brevity contributes to the low informational density. Structure is good but not exceptional.
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 (13 parameters, no output schema, no annotations), the description is severely under-specified. It gives a high-level purpose but fails to explain what the generated templates look like, how to use them, or context around pagination and queueable skeletons. It is far from 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 13 parameters. It doesn't explain the difference between soqlQuery and objectName, the meaning of fetchSize, or when to set usePaginationCursor. The tool relies entirely on parameter names, which are insufficient for correct invocation.
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 builds SOQL and Apex cursor code templates, with a specific verb 'Build' and resource 'SOQL and Apex cursor code templates'. It distinguishes from execution-focused siblings like sf_execute_apex_cursor_query, though it lacks exact output details. Not a full 5 because 'cursor' and 'templates' could be more precisely defined.
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 on when to use this tool versus alternatives. It implies use for large-record processing, but doesn't mention related tools like sf_execute_apex_cursor_query or sf_execute_batch_job. No exclusions or prerequisite context provided.
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?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing any behavioral details, such as whether partial failures occur, what the 'confirm' parameter does, whether it supports bulk creation, or whether any targetOrg/directory context is required. For a mutating operation, this is a significant gap.
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 a single, concise sentence that is easy to read, but it is under-specified. While it earns its place by stating the core action, it omits context and parameter details that could be included without much verbosity. It is not as concise as a well-structured description that front-loads critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no annotations, and no output schema, the description is far from complete. It does not explain required inputs, expected outcomes, or how it relates to the Salesforce environment (e.g., targetOrg, directory). This is inadequate for an agent to confidently select and invoke the tool correctly, especially given the large set of Salesforce sibling tools.
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 0%, and the description adds no explanation for any of the five parameters (confirm, records, directory, targetOrg, objectName). It only mentions 'records' implicitly through 'Create records,' but even that is more of the tool's purpose than a parameter explanation. The description does not compensate for the schema's lack of 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 clearly states the tool's action: 'Create records in a Salesforce object using jsforce.' This uses a specific verb ('create') and resource ('records in a Salesforce object'), distinguishing it from sibling tools like sf_update_records, sf_delete_records, and sf_upsert_records. The mention of jsforce is an implementation detail but does not obscure 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 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 such as sf_upsert_records or sf_update_records. It does not mention scenarios, prerequisites, or conditions that would make this tool preferable.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state that deployment is a write/destructive operation, whether it waits for completion, handles conflicts, or requires confirmation. The agent is unaware of side effects or prerequisites.
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 sentence with no wasted words, clearly front-loading the core purpose. It is appropriately concise for the minimal information it conveys, though this brevity contributes to its overall insufficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 9 parameters, no output schema, and no annotations, this description is severely inadequate. It omits return values, status monitoring, side effects, preconditions, and relationships to related deployment tools, leaving the agent without essential execution context.
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 schema has 9 parameters with 0% description coverage, and the description adds no parameter explanations. The phrase 'local project files' hints at directory/sourceDir but does not clarify their semantics, leaving the agent to guess how to fill any of the parameters.
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 action (deploy), the resource (Salesforce metadata), and the source (local project files). This distinguishes it from retrieve/list tools, though it does not explicitly mention the target org or differentiate from the validate tool.
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?
There is no guidance on when to use this tool versus alternatives like sf_deploy_metadata_validate or sf_get_deploy_status. The description only states what it does, leaving the agent to infer the appropriate context without any exclusion or alternative references.
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?
With no annotations, the description must disclose behavioral traits, but it only says 'Delete records' without mentioning irreversibility, confirmation requirements, permission needs, or effects on related data. The confirm parameter in the schema is not explained.
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 single sentence that is front-loaded and free of fluff. While it under-specifies important details, the structure itself is clean and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with five parameters, no annotations, and no output schema, the description is severely incomplete. It lacks parameter explanations, behavioral warning, return value info, and usage context, making it inadequate for safe selection and invocation.
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 0%, and the description does not explain any of the five parameters (objectName, ids, confirm, directory, targetOrg). The agent gets no added meaning beyond the raw JSON 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 (Delete) and the resource (records in a Salesforce object). This distinguishes it from sibling tools like create, update, and query, which perform different operations.
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 about when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent to infer usage solely from the name.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the mechanism ('creating a TraceFlag') but fails to disclose side effects, permission requirements, whether existing TraceFlags are replaced, expiration behavior, or the impact on the user's logging. For a mutation tool, this is a significant gap.
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 a single concise sentence and front-loaded with the action. However, it is under-specified for a tool with 7 parameters, making the brevity a drawback rather than a virtue. It could earn a higher score if it included more essential details without becoming verbose.
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 (7 params, no annotations, no output schema), the description is severely incomplete. It provides no information about return values, error conditions, parameter semantics, or usage context. While it states the purpose, an agent has insufficient information to invoke the tool correctly in real scenarios.
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 0%, and the description does not explain any of the 7 parameters. The phrase 'for a user' hints at username, but that is already obvious from the schema property. The meanings of confirm, logType, directory, targetOrg, expirationMinutes, and debugLevelDeveloperName are entirely undocumented, leaving the agent unable to set them 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 the action ('Enable debug logs'), the target ('for a user'), and the mechanism ('by creating a TraceFlag'). This is a specific verb+resource that distinguishes it from sibling tools like sf_disable_debug_logs and sf_list_debug_logs.
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. It does not mention prerequisites, when to avoid, or how it relates to sf_disable_debug_logs or other logging tools. The agent is left without context for choosing this tool.
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?
No annotations are provided, so the description carries the full burden. It states the action (retrieve to local files) but does not disclose side effects like overwriting existing files, whether authentication is needed, or if the operation is asynchronous. The description gives a shallow summary without important behavioral traits such as potential error conditions or whether it prompts for confirmation.
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, focused sentence that states the core function without any fluff or redundancy. It is appropriately succinct and front-loaded with the essential action, earning a high score for conciseness.
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 7 optional parameters and no output schema, the description is far from complete. It does not explain the return value, the structure of local files modified, any required Salesforce connection, or how parameters like manifest and metadata interact. Given the tool's complexity, a single sentence is inadequate 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description itself provides no explanation of any of the 7 parameters. The parameter names (wait, manifest, metadata, directory, sourceDir, targetOrg, packageName) are somewhat self-explanatory, but the description adds no value in clarifying their roles. Since the description must compensate for the low schema coverage and does not, this scores very low.
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 purpose: 'Retrieve metadata from a Salesforce org to local project files.' It uses a specific verb (retrieve) and resource (metadata) and adds the destination (local project files), which distinguishes it from deploy or list operations. However, it does not explicitly differentiate from siblings like sf_list_metadata or sf_deploy_metadata, so it loses one point.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, such as requiring an authenticated org or a specific project structure, nor does it explain when a user would prefer this over sf_deploy_metadata or sf_list_metadata. This lack of usage context leaves the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects. It does not state that scheduling is a mutating operation, whether confirmation is required (despite the 'confirm' parameter in the schema), or what happens on success. The description is completely devoid of 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, making it efficient to parse. However, it is almost too brief to be useful, sacrificing substance for brevity. It earns a 4 because it contains no waste, but the conciseness is not appropriately balanced with completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has six parameters, no output schema, and no annotations, yet the description only states the basic purpose. It does not explain the meaning of required parameters, the confirmation behavior, target org selection, or return values. This is completely inadequate for an agent to safely and correctly invoke 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 indirectly references 'cron expression' and 'Schedulable Apex class,' which loosely map to cronExpression and className. However, it fails to explain jobName, confirm, directory, targetOrg, or the expected format of the cron expression. With 0% schema description coverage, the description only partially compensates for two of six 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 clearly states the action ('Schedule a Schedulable Apex class') and the method ('using a cron expression'). This is a specific verb+resource combination that distinguishes it from sibling tools like sf_unschedule_apex_job or sf_execute_batch_job.
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. It does not mention prerequisites (e.g., the class must implement Schedulable), exclusions, or that unscheduling uses a different tool. There is no context to help the agent choose correctly among related scheduling tools.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the action and source but does not mention output format, limitations, whether it is read-only, or any other behavioral nuances. This is thin even for a simple listing tool.
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 single, concise sentence that is front-loaded with the action and resource. There is no wasted text, and it is easy to parse. It earns a high score for efficiency, though it sacrifices depth.
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 no annotations, the description lacks essential context such as return value structure and parameter effect. The tool may be simple, but the description does not adequately prepare an agent to use it correctly, especially with an optional parameter that is undocumented.
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 single parameter limitPerDomain is not described in the text, and schema coverage is 0%. The parameter name gives a hint, but the description does not clarify how it affects the output or what 'sample skills' means in relation to the limit. The description fails to compensate for the lack of schema documentation.
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 a specific verb ('List') and resource ('skill domains and sample skills from forcedotcom/sf-skills'), making it distinct from generic listing tools. However, it does not explicitly differentiate from sibling tools like sf_skills_search or sf_skills_get, so it falls short of a perfect score.
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?
There is no guidance on when to use this tool versus alternatives. The description only states what it does, not the context in which it should be preferred over similar tools like sf_skills_search or sf_skills_get.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that a query is run, but does not mention read-only nature, side effects, rate limits, or return format. As a query tool, it is likely safe, but this is not disclosed.
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 single, concise sentence with no redundant words. It is front-loaded with the action and resource. However, it is so brief that it lacks substantive content, though this is a correctness issue, not a conciseness flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema or annotations, this description is severely incomplete. It does not explain the query syntax, the purpose of directory/targetOrg, or what the return value looks like. The tool cannot be correctly invoked based on this description alone.
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 0%, and the description provides no parameter-level meaning. The query parameter is implied by the description, but directory and targetOrg are completely unexplained. The description does not compensate for the missing schema 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 the action ('Run a SOQL query') and the target resource ('Salesforce Tooling API objects'), distinguishing it from sibling tools like sf_query_org that target the standard API. The verb 'Run' and noun 'query' are specific, and 'Tooling API' differentiates it from other query tools.
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 usage guidance is provided. There is no mention of when to use this tool versus alternatives such as sf_query_org, sf_search_org, or sf_execute_named_query. The description implies the tool is for Tooling API queries but does not state exclusions or alternatives.
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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Cancel a running deployment', but doesn't disclose side effects such as irreversibility, what happens if the deployment has already completed, or whether confirmation is required. The presence of a 'confirm' boolean parameter is not mentioned at all, which is a significant omission.
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, tightly worded sentence. It is front-loaded with the action and immediately states the key identifier. Every word earns its place, and there is no redundant or filler content. This is appropriately concise for a simple cancel operation.
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 has 4 parameters, no output schema, and no annotations, the description is quite incomplete. It doesn't explain what the response will be, how to handle errors (e.g., job not running), or the meaning of the optional parameters. While the core action is clear, the tool's usage context is insufficiently specified for an agent to invoke it confidently in a complex scenario.
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 0%, so the description must compensate for parameter meaning. It only explains 'deploy job id' (mapping to jobId), but leaves 'confirm', 'directory', and 'targetOrg' completely unexplained. Even though jobId is the only required parameter, the other parameters' purpose and format are entirely absent from the description, offering minimal value over the raw 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 'Cancel a running deployment by deploy job id', which uses a specific verb (cancel), identifies the resource (deployment), and names the key parameter (deploy job id). This distinguishes it from sibling tools like deploy, validate, and get status. However, it doesn't explicitly reference alternatives or ceding conditions, so it lacks a bit of differentiation 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a deployment is running and needs to be cancelled, but it provides no explicit when-to-use, when-not-to-use, or alternative tool references. It doesn't mention that a deployment must be active or that other tools like get_deploy_status might be used first to obtain the job id or confirm the state.
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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It simply says 'Get' without detailing authentication requirements, pagination behavior, rate limits, or any side effects. The read-only nature is implied but not explicitly stated, and no other operational characteristics are revealed.
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, direct sentence that front-loads the action ('Get') and resource ('Chatter feed elements'). It contains no filler or redundancy, making it appropriately concise for the minimal information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no output schema, and no annotations, this one-line description is grossly insufficient. It fails to explain how parameters like directory and targetOrg affect the request, what the response format looks like, or any pagination or filtering behavior. The description does not provide the context needed for correct invocation.
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 0%, and the description does not mention or clarify any of the four parameters (pageSize, recordId, directory, targetOrg). The description adds no meaning beyond what the schema names already imply, leaving parameter semantics entirely undocumented.
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 ('Get') and the resource ('Chatter feed elements for a Salesforce record'), making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like sf_chatter_post_to_record and sf_query_org by specifically targeting Chatter feed retrieval.
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. It does not mention prerequisites, exclusions, or why one would choose this over similar query tools. The only implied usage is from the tool's name, but no explicit context is given.
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 does not disclose side effects, such as file overwriting, deployment to org, or the meaning of 'baseline'. Since no annotations are present, the description carries the full burden, and it fails to mention important behavioral factors like the overwrite/confirm/deployAfterGenerate parameters.
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?
A single sentence that is efficient and front-loaded with the action verb, containing no filler words. It earns its place as a concise summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters and no annotations or output schema, this one-sentence description is grossly insufficient. It lacks information about return values, prerequisites, conflict handling, and deployment behavior.
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?
With 0% schema description coverage and no parameter explanations in the description, the semantics of 12 parameters (e.g., overwrite, exposeTargets, ignoreConflicts) are entirely unclear. The description only mentions 'baseline' without elaborating.
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: generating baseline LWC component files within a Salesforce project. It uses a specific verb ('Generate') and resource ('LWC component files'), distinguishing it from the many query/execute/deploy sibling tools.
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?
There is no guidance on when to use this tool vs alternatives, or under what conditions (e.g., replacing existing components, handling conflicts). No prerequisites or exclusions are mentioned.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only permission check but does not explicitly state that it is non-destructive, describe the return format, or clarify behavior when multiple objects are passed. This is minimal disclosure for a tool that could be used to prevent unauthorized operations.
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 with no filler or redundancy. Every word contributes to the core purpose, making it an effective and efficient statement of the tool's function.
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 has four parameters, no output schema, and no annotations. The description fails to explain optional parameters, return structure, or error behavior, and it does not differentiate the tool from similar siblings. This is insufficient for an agent to safely and accurately invoke the tool in all intended contexts.
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 0%, so the description must compensate. It conveys the meaning of userId and objectApiNames ('single user' and 'one or more objects'), but leaves directory and targetOrg unexplained. These optional parameters likely affect org targeting, and the description does not clarify their purpose.
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 the specific verb 'Check' and clearly identifies the resource: object-level create permission for a single user across one or more objects. It distinguishes the tool from generic query tools, though it does not explicitly differentiate it from its close sibling sf_get_user_record_access.
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 like sf_get_user_record_access. The description states only what the tool does, with no mention of use cases, prerequisites, or exclusions, leaving the agent to infer the appropriate context.
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?
There are no annotations, and the description offers no behavioral details beyond the basic action. It does not disclose result format, authentication requirements, target org handling, or potential errors. A single sentence leaves the agent without insight into side effects or preconditions.
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, focused sentence with no redundant words. It is front-loaded with the action and resource, making it efficiently scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 0% parameter description coverage, the description provides only the minimal purpose. It fails to explain parameters or usage context, making it inadequate for correct tool invocation.
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 0%, and the description does not explain any of the three parameters (search, directory, targetOrg). The agent cannot infer what values are expected or how they affect the search.
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 ('Run a SOSL search') and the resource ('a Salesforce org'). It distinguishes itself from sibling tools like sf_query_org by specifying SOSL rather than SOQL, making it easy to differentiate.
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 SOSL search versus SOQL query or other alternatives. The description does not mention any context such as 'use for full-text search across objects' or 'use instead of sf_query_org for SOSL.'
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 is minimal and does not disclose behavior such as whether it returns first or all matches, what happens on missing elements, how sessionId is used, or whether any side effects occur. With no annotations, this is a substantial gap.
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?
A single sentence that is efficient and front-loaded. No unnecessary words, so it earns a high score for conciseness.
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?
For a tool with 5 parameters and no output schema, the description is under-specified. It lacks details on return values, matching behavior, and parameter semantics, making it insufficient for reliable autonomous use.
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 0%, and the description only hints at the 'attribute' parameter via 'text or attributes.' It does not explain selector, all, sessionId, or timeoutMs, leaving the agent to infer their meaning.
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 states a specific action ('Extract text or attributes') and a target ('page elements'), clearly identifying the tool's function. It distinguishes this from sibling UI tools like ui_navigate or ui_action, though it doesn't explicitly name alternatives.
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 about when to use this tool versus other UI tools such as ui_assert or ui_screenshot. There is no mention of prerequisites (e.g., a running session) or exclusion scenarios.
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?
With no annotations, the description must disclose behavioral traits, but it only says 'Get,' implying a read operation without explicitly stating that it does not modify state. It does not disclose what happens if the directory parameter is omitted, whether it can fail, or any side effects. Minimal transparency beyond the basic operation.
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 with no filler words. Every part of the sentence contributes to understanding the tool's core function, and it is appropriately concise.
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 minimal schema and no output schema, the description does not explain how 'the current project' is determined, what happens with the optional directory parameter, or what the return format looks like. For a simple tool, some of this context is missing, making the description incomplete.
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 input schema has one parameter 'directory' with no description, and the schema coverage is 0%. The description does not mention this parameter at all, leaving the agent to guess its meaning, purpose, and default behavior. The description fails to compensate for the lack of schema 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 uses the specific verb 'Get' with the resource 'git branch and working tree status,' clearly indicating the tool's function. It distinguishes itself from sibling git tools (e.g., git_recent_commits, git_file_history) by focusing on status rather than commit history.
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 about when to use this tool versus alternatives, no prerequisites are mentioned (e.g., must be in a git repository), and there are no exclusions. The description states only what the tool does, not 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of disclosing behavioral traits. It only states the action without mentioning required permissions, side effects on user access, confirmation requirements (despite a 'confirm' parameter), or reversibility. This is insufficient for a mutation tool.
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 single concise sentence with no filler. It front-loads the action and resource, making it immediately clear what the tool does. However, its brevity contributes to the lack of behavioral and parameter detail.
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 (5 parameters, mutation, no output schema, no annotations), the description is severely incomplete. It does not explain key parameters like 'onBehalfOfUser' or 'confirm', and provides no context on when or how to use it safely. The description would not enable an agent to invoke the tool correctly without additional knowledge.
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 5 parameters with no descriptions (0% coverage). The description only adds meaning to 'permissionSetGroupNames' via 'one or more', but fails to explain 'confirm', 'directory', 'targetOrg', and 'onBehalfOfUser'. The description does not compensate for the schema's lack of parameter 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 the tool's function with a specific verb ('Assign'), resource ('permission set groups'), and target ('a user in Salesforce'). The phrase 'one or more permission set groups' distinguishes it from the sibling sf_assign_permission_set, which likely handles single permission sets.
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. The description does not mention the singular permission set assignment tool (sf_assign_permission_set) or removal tools, nor does it specify scenarios where this tool is preferred. With a clear sibling distinction available, this is a missed opportunity.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Create', which implies a write operation, but does not mention side effects like user activation status, required permissions, or the presence of a 'confirm' parameter that might require confirmation before creation.
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, concise sentence that is front-loaded with the action 'Create' and the resource 'Salesforce User record'. Every word contributes to the core message, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters, no output schema, and no annotations, this one-sentence description is severely under-specified. It fails to mention required fields, operational prerequisites, or any guidance on how the tool behaves, making it inadequate for an AI agent to correctly select and invoke 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 mentions 'profile and locale settings', which loosely maps to parameters like profileName, profileId, localeSidKey, etc. However, with 16 parameters and 0% schema description coverage, it does not explain the required fields (username, email, lastName, alias) or other essential parameters, leaving most parameters undefined.
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 'Create a Salesforce User record' with a specific verb and resource, distinguishing it from generic tools like sf_create_records. Referencing profile and locale settings further clarifies the tool's specific scope.
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 such as sf_create_records or sf_update_records. There is no mention of prerequisites, disambiguation, or scenarios where this tool is 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?
With no annotations, the description carries the transparency burden. It reveals that the tool returns schema details including fields and relationships, implying a read-only operation. However, it does not explicitly mention that it is safe, require authentication, or disclose any other behavioral traits. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It efficiently states the tool's purpose, but it omits critical details. Given its brevity, the structure is not wasteful, earning a good score, though not maximal because it sacrifices substance.
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 has no annotations, no output schema, and a 0% schema description coverage. The one-sentence description leaves the agent without enough context to understand the parameters (directory, targetOrg) or the return shape. This is insufficient for reliable tool invocation.
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 zero descriptions for all three parameters (directory, targetOrg, objectName), and the description does not explain any of them. Only objectName is self-evident from its name; directory and targetOrg remain ambiguous. The description fails to compensate for the 0% schema description coverage.
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 describes a Salesforce object schema, specifically including fields and relationships. This distinguishes it from querying records (e.g., sf_query_org) and metadata listing (sf_list_metadata), though it doesn't explicitly differentiate from the sibling tool sf_tooling_describe_object.
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, such as sf_query_org or sf_tooling_describe_object. It lacks exclusions, prerequisites, or context for selecting this tool over siblings.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'execute' without indicating whether the operation is read-only, what mutations may occur, whether it requires specific permissions, or what errors might arise. This is minimal and insufficient for an agent to anticipate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is so terse that it lacks essential contextual information, making it 'under-specification' rather than ideal conciseness. It earns a 4 for structure but loses a point for being overly minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are 4 parameters (including a nested object), no output schema, and no annotations, this one-sentence description is grossly incomplete. An agent would not know what 'directory' or 'parameters' refer to, what the tool returns, or when to invoke it compared to other query tools.
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 0%, and the description only mentions 'query API name' (mapping to queryApiName). It does not explain 'directory', 'targetOrg', or the nested 'parameters' object, leaving the agent without any semantic understanding of these fields. The description adds partial value for one parameter but fails to compensate for the rest.
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: it executes a Salesforce Named Query API resource, identified by query API name. This is a specific verb+resource combination that distinguishes it from sibling tools like sf_query_org (SOQL query) or sf_execute_anonymous_apex (Apex execution).
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 such as sf_query_org, sf_search_org, or sf_execute_anonymous_apex. There is no mention of preferred use cases, prerequisites, or when it should not be used.
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?
With no annotations provided, the description carries the full burden. It does not disclose behavioral traits such as the wait parameter's polling/blocking nature, what 'details' include, or whether any side effects exist. The simple statement 'Get deployment status' gives no operational 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 a single, concise sentence with no fluff, making it easy to parse. However, it is under-specified and lacks helpful details, so it earns a slightly lower score than a fully informative concise description.
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?
For a tool with 4 parameters, a wait option, and no output schema, the description is incomplete. It does not explain what status details are returned, how the wait parameter behaves, or the roles of directory and targetOrg, leaving significant gaps for the agent.
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 4 parameters with 0% description coverage, and the description only mentions 'deploy job id' (jobId). It does not explain the purpose of wait, directory, or targetOrg, leaving the agent with no additional meaning beyond the 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 clearly states the tool retrieves deployment status and details using a deploy job ID, which is specific and distinguishes it from siblings like sf_deploy_metadata or sf_cancel_deploy. The verb 'Get' and resource 'deployment status and details' are explicit.
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 instead of alternatives, such as after running a deployment or to poll for completion. The only implied usage is from the phrase 'by deploy job id,' but there is no explicit context or exclusion.
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?
There are no annotations provided, so the description must disclose behavioral traits. However, it only states the action and does not mention read-only nature, required permissions, output format, or side effects. This is a significant gap.
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 concise sentence that directly states the tool's purpose with no unnecessary words. It is well-structured and front-loaded with the action verb.
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?
For a tool with three optional parameters, no annotations, and no output schema, the description is insufficiently complete. It does not explain parameter purposes, expected output, or operational context, leaving an agent with limited understanding of how to invoke it correctly.
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 schema has three parameters with no descriptions, and the tool description does not explain any of them. With 0% schema description coverage, the description fails to add meaning to parameters like 'verbose', 'directory', or 'targetDevHub'.
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 'List' and a clear resource 'second-generation packages', scoped to 'Dev Hub org'. It clearly distinguishes from sibling tools like sf_package_create and sf_package_install, which are write operations.
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 over alternatives, no prerequisites, and no exclusions. It simply states what it does without contextual usage hints.
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?
With no annotations, the description must disclose behavioral traits, but it only states the core action. It does not mention that this is a destructive operation, whether confirmation is needed, or how it affects existing permissions. The presence of a 'confirm' parameter is not explained.
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 single concise sentence that immediately communicates the core function. It is not verbose, though possibly too brief to be fully useful.
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 has five parameters, no annotations, and no output schema, a single sentence is insufficient. The description lacks information about required context (e.g., target org, user identity), the meaning of confirmation, and the operational impact.
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 0% description coverage and the description does not explain any parameters. It implies 'permissionSetGroupNames' are the groups to remove, but leaves 'confirm', 'directory', 'targetOrg', and 'onBehalfOfUser' completely unexplained.
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 removes one or more permission set groups from a user in Salesforce, using a specific verb and resource. It differentiates from sibling tools like sf_remove_permission_set by explicitly referring to 'permission set groups'.
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 such as sf_remove_permission_set or sf_assign_permset_group. It does not mention any prerequisites or contexts.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool runs Apex test suites, but does not disclose whether execution is synchronous, whether it waits for results, what side effects occur, or any authentication/visibility 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 a single, front-loaded sentence with no filler or redundancy. While it is concise, it is also so terse that it omits important context, preventing a perfect score for 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?
Given the tool has 5 parameters, no annotations, and no output schema, the description is incomplete. It does not explain what happens when tests run, what the result looks like, or how parameters like wait and codeCoverage affect execution, leaving major gaps for an agent.
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 0%, and the description only adds the vague hint 'suite-first input' without explaining the meaning or usage of wait, directory, targetOrg, or codeCoverage. This fails to compensate for the schema's lack of parameter 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 identifies the action ('Run') and resource ('Apex test suites'), and the parenthetical 'suite-first input' distinguishes it from sibling sf_run_apex_test, which likely handles individual tests. However, it doesn't explicitly state what distinguishes it from all related tools, so it falls just 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 implies use when running Apex test suites, but it provides no explicit guidance on when to choose this tool over alternatives like sf_run_apex_test or other testing utilities. No exclusions or alternative references are given.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It fails to mention that unscheduling is a destructive/mutating action, whether confirmation is needed, what happens to running jobs, or any side effects such as aborting all matches. The existence of parameters like confirm and abortAllMatches hints at significant behavior that is not disclosed.
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 single short sentence that is front-loaded with the action verb and is free of fluff. It earns its place by stating the core purpose, but it lacks any structural elements (e.g., separators, examples, or parameter notes) that would help an agent parse more complex behavior. It is concise but minimal to the point of being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, no output schema, and 0% schema description coverage, a one-sentence description is completely inadequate. It does not explain the semantics of confirmation, abortAllMatches, directory, or targetOrg, nor does it warn about consequences of unscheduling jobs. The agent would have no idea how to properly invoke this tool beyond the basic action.
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 0%, so the description must compensate. It only mentions jobId and jobName, providing minimal meaning for these two parameters, but leaves confirm, directory, targetOrg, and abortAllMatches completely unexplained. The tool has 6 optional parameters with no required fields, which is confusing and not clarified by the description.
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 'Unschedule' and the resource 'scheduled jobs', with a qualifier 'by jobId or jobName' that specifies the identification method. This distinguishes it from sibling tools like sf_schedule_apex_job and sf_execute_batch_job, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites. It mentions jobId or jobName as options but does not explain when to prefer one over the other or when not to use the tool. The inverse relationship with sf_schedule_apex_job is implied but not stated.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that the tool checks visibility and text, but gives no information about what happens on assertion failure, whether it interacts with a browser session, or any side effects. This is insufficient for an agent to understand the tool's runtime behavior.
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 single concise sentence that is front-loaded with the core idea. It is efficient and easy to parse, though it is too brief to convey essential details. The structure is appropriate for a simple tool, but the content is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, no output schema, and no schema descriptions, the description is severely incomplete. It does not explain what selector means, how timeoutMs behaves, or what the return value or success/failure semantics are. An agent cannot reliably use this tool based solely on this description.
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 no descriptions for any of the 5 parameters, and the tool description only adds 'visibility and text', which loosely maps to visible and textContains. The critical parameters selector, sessionId, and timeoutMs remain completely unexplained, leaving the agent without understanding how to invoke the tool 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 'Assert' with a clear resource ('UI conditions') and narrows the scope to 'visibility and text'. This distinguishes it from sibling tools like ui_action (which performs actions) and ui_extract (which extracts data).
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. It merely states the generic purpose without any context about when assertions are appropriate or how it differs from other UI tools. The usage is only implied by the verb 'Assert'.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. It reveals that the screenshot comes from the 'current UI session', implying a dependency on an active session, but it doesn't mention what happens if no session exists, how the screenshot is returned, or any side effects. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the verb and resource directly, making it highly efficient and easy to parse.
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?
Despite being a simple tool, the description is incomplete. It does not explain what the screenshot captures, how it is returned, or what the optional parameters do. The lack of an output schema and annotations makes this a significant gap 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the three parameters (fileName, fullPage, sessionId). The description adds no meaning beyond the raw parameter names, leaving the agent without guidance on how to use them.
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 ('Capture') and clearly identifies the resource ('a screenshot from the current UI session'). It is distinct from sibling tools like 'ui_extract' or 'ui_navigate', as capturing a screenshot is a unique operation.
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, nor does it mention prerequisites like having an active UI session. It simply states the action without any context on appropriate usage scenarios.
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?
No annotations are provided, so the description must fully disclose behavior. It states that sessions are ended and trace info is returned, but it does not explain side effects (e.g., whether ending is destructive, if it applies to all sessions or a specific one, or any prerequisites). The presence of parameters like endAll and sessionId is not reflected in the description.
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 single concise sentence that immediately conveys the core function and expected return. It is front-loaded and contains no unnecessary words, though it may be too brief relative to the tool's complexity.
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 8 optional parameters, no annotations, and no output schema, the description is insufficiently detailed. It does not explain how to specify which sessions to end (endAll vs sessionId), how to target an org, or what 'trace info' includes. The tool's behavior is likely more complex than the description suggests.
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 input schema contains 8 parameters with 0% description coverage. The tool description does not mention any parameter names, purposes, or how they relate to ending sessions. The agent receives no additional meaning beyond the raw schema, so it cannot correctly determine parameter 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 action ('End Agentforce preview sessions') and the additional output ('return trace info'). It is specific and distinguishes this tool from siblings like sf_agent_preview_start, sf_agent_preview_send, and sf_agent_preview_sessions.
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?
No explicit guidance on when to use this tool versus alternatives. The purpose is understandable, but the description does not mention exclusions or contrast with sibling tools. Usage is implied by the name and action rather than explained.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action. It does not mention side effects, prerequisites beyond an existing session, return values, error behavior, or any lifecycle considerations.
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 single, front-loaded sentence with no filler words. It earns its place by stating the core action and target, though it is too sparse to fully support the tool's complexity.
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 eight parameters, no annotations, and no output schema, a one-sentence description is inadequate. It hints at a session prerequisite but lacks critical context about how to identify the session, what parameters are needed, or what the response will be.
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 0%, and the description adds no meaning beyond the schema property names. 'utterance' is simply repeated from the schema without elaboration, and the other seven parameters (e.g., sessionId, apiName, targetOrg) are entirely unexplained.
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 ('send') and clearly identifies the resource ('an utterance') and target ('an existing Agentforce preview session'). This distinguishes it from sibling tools like sf_agent_preview_start and sf_agent_preview_end, making its purpose immediately 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 phrase 'existing preview session' implies the tool should be used after a session is started, but it does not explicitly state when to use it versus alternatives or provide exclusion criteria. Usage is implied rather than directly guided.
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?
With no annotations, the description carries the burden. It discloses that data comes from a local cache, implying a read-only, offline operation. However, it does not mention what a session is, how many results are returned, or what happens if the cache is empty or the directory is invalid. It provides some behavioral context but not full transparency.
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 single sentence with no wasted words, front-loading the core action. It is concise, though it sacrifices detail for brevity.
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?
Despite the tool's low complexity (1 optional parameter, no output schema), the description is incomplete. It fails to explain the 'directory' parameter, the format of returned sessions, or how this relates to the other Agentforce preview tools. Nested information is absent.
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?
There is one parameter, 'directory', with no schema description (0% coverage). The tool description does not mention this parameter at all, leaving its purpose and format entirely unexplained. The description adds no meaning beyond the schema's bare type declaration.
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 ('List') and a clear resource ('locally cached Agentforce preview sessions'), distinguishing it from sibling tools like sf_agent_preview_start, send, and end. It immediately conveys what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool, no conditions, and no mention of alternatives. It is a bare statement without context or exclusions.
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?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. Yet it only states the purpose and location ('in a Dev Hub org'), omitting details about side effects, required permissions, whether the package is created locally or remotely, or any irreversible actions taken.
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, concise sentence that immediately conveys the core action and target context. It contains no filler or repetition, and the structure is front-loaded with the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, no output schema, no annotations), the description is severely insufficient. It does not explain what the package creation entails, expected outputs, error conditions, prerequisites, or the significance of the Dev Hub requirement, leaving an agent without enough context to invoke the tool safely and correctly.
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 provides no information about the 11 parameters, and schema description coverage is 0%. Since the schema only lists parameter names and types, the description fails to explain the meaning, purpose, or relationships of parameters like 'name', 'path', 'packageType', or 'confirm'.
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 ('Create') and resource ('second-generation Salesforce package'), and adds context ('in a Dev Hub org'). It distinguishes from sibling tools like sf_package_install and sf_package_list by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: if you want to create a package, use this tool. However, there is no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites, leaving room for ambiguity in tool selection.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action, not ordering, pagination, default limits, or whether specific parameters like directory are required to disambiguate paths. There is no mention of output format or potential side effects, leaving the agent with minimal behavioral 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 a single sentence that directly states the purpose without filler or redundancy. It is front-loaded with the primary action and resource, making it easy for an agent to parse quickly. Every word earns its place, though it sacrifices completeness (addressed in other dimensions).
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 has three parameters, no output schema, and no annotations, yet the description only covers the main purpose and one parameter. It does not elaborate on usage context, parameter roles, or expected return, leaving the agent with insufficient information to correctly invoke the tool in varied scenarios. For a simple tool this is incomplete given the lack of structured context.
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 0%, so the description must compensate for the parameters. It only implicitly explains 'filePath' as the 'specific file path,' but does not explain 'limit' (e.g., maximum entries) or 'directory' (how it is used to resolve the path). The description adds little beyond the parameter names, failing to define the semantics for two of the three 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 uses a specific verb 'List' plus resource 'commit history entries' and scopes it to 'a specific file path,' clearly differentiating it from sibling tools like git_recent_commits (recent commits generally), git_last_commit_for_file (only the last commit), and git_last_commit_files (files in the last commit). This provides immediate clarity on the tool's core function.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that this should be used when you need the full commit history for a file as opposed to git_recent_commits for a broad overview or git_last_commit_for_file for just the most recent commit. Without exclusion or alternative suggestions, the agent has no direction 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?
With no annotations, the description carries the transparency burden. It implies a read-only listing and clarifies output is 'names only,' but it does not disclose behavior around the directory parameter, error cases, or whether paths are absolute or relative.
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, tightly worded sentence with no filler. Every word contributes meaning, stating exactly what the tool does and the output scope.
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 too sparse for a tool with an undocumented parameter and no output schema. It omits clarification on the directory argument, default behavior, and return format specifics, leaving gaps for successful invocation.
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 sole parameter 'directory' has no schema description and is entirely unmentioned in the tool description. The agent gets no guidance on what this string should be or how it affects the result, making the parameter effectively opaque.
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 file paths changed in the latest commit, with 'names only' indicating scope. This distinguishes it from sibling tools like git_last_commit_for_file (which filters by file) and git_recent_commits (which lists commits).
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 scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the name and description.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core action and does not mention important traits like whether directory is required or optional, branch scope, behavior when the file is not found, or any side effects. This is insufficient.
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 directly conveys the purpose. Every word earns its place; there is no padding or redundancy.
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?
For a tool with only two parameters, no output schema, and no annotations, the description should provide more context about usage, behavior, and result format. The current description is a minimal, functional statement but lacks the depth needed for an agent to confidently select and invoke the tool in diverse scenarios.
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 zero description coverage and the tool description does not compensate. The two parameters, 'filePath' and 'directory', are not explained beyond the implicit meaning of 'file'. 'directory' is completely unexplained, and there is no mention of required vs optional or expected format.
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 specific action ('Find the most recent commit') and the resource ('a specific file'), which distinguishes it from sibling tools like git_recent_commits (which likely lists commits without file focus) and git_last_commit_files (which likely lists files in the last commit). The phrase 'where a specific file changed' provides clear scope.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or contrast with sibling tools such as git_file_history or git_recent_commits. This is a clear gap.
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?
With no annotations, the description carries the burden of behavioral disclosure. It states the output includes author, date, and message, and implies recency, but does not mention ordering, default limits, or read-only nature. For a simple read tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is immediately clear and front-loaded with the action and resource. No wasted words.
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?
For a simple tool with no output schema and no annotations, the description is minimal but lacks essential parameter semantics. It does not clarify how directory or limit affect the results, or how this differs from related git tools. The description is not fully complete for an AI agent to use confidently.
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 schema has 0% description coverage, and the tool description does not explain the limit or directory parameters. The agent is left to guess the meaning and format of these optional parameters, which is a significant 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 uses the specific verb 'List' with the resource 'recent git commits' and explicitly mentions the included fields (author, date, message). This clearly distinguishes it from sibling git tools that focus on individual files, status, or file history.
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 like git_file_history or git_last_commit_for_file. The description only states what it does, not the context for choosing it over siblings.
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?
With no annotations provided, the description must disclose behavioral traits. It only states 'Create,' implying a write operation, but does not mention side effects, permissions, reversibility, or post-creation state. This is minimal disclosure and leaves significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and object. There is no fluff or redundancy—every word earns its place, making it easy to parse quickly.
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?
Despite having 8 parameters, no output schema, and no annotations, the description provides only the core purpose and input source. It omits important context such as parameter usage, required fields beyond the spec file, environment considerations, and expected outcomes. This is inadequate for safe and correct invocation in most scenarios.
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 lists 8 parameters with 0% coverage in the description. The description adds meaning only for 'specPath' via 'local agent spec file,' but does not explain 'name', 'apiName', 'confirm', 'preview', 'directory', 'targetOrg', or 'apiVersion'. This leaves agents to guess semantics from parameter names 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 the action ('Create') and the resource ('an Agentforce agent') plus the source ('from a local agent spec file'). This specific verb+resource combination uniquely distinguishes it from sibling tools like sf_agent_activate or sf_agent_deactivate.
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 or when not to use it. It does not mention prerequisites, target org, or relationship to other agent lifecycle tools, leaving the agent to infer usage from the name and description.
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?
There are no annotations, so the description carries the full burden. It only states the action without disclosing that it mutates data, whether it is reversible, or any required permissions. The lack of behavioral details is a significant gap for a mutation 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?
The description is a single, clear sentence. It contains no filler and gets straight to the point, making it easy to parse and remember.
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 has 5 parameters and no output schema or annotations, yet the description only covers the core action. It omits details about optional parameters, side effects, return values, or error conditions, making it incomplete for an agent to invoke without additional clarification.
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 5 parameters with 0% description coverage, so the description must compensate. It only mentions 'permission sets' and 'a user', which vaguely map to permissionSetNames and onBehalfOfUser, but leaves confirm, directory, and targetOrg unexplained. This is insufficient for selecting and 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 the verb 'assign', the resource 'permission sets', and the target 'a user', while noting support for multiple sets. This distinguishes it from sibling tools like sf_remove_permission_set, which performs the opposite action.
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, such as sf_remove_permission_set or sf_assign_permset_group. It does not mention prerequisites like selecting the targetOrg or when assignment is appropriate, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic action without disclosing side effects, prerequisites, permissions, or response behavior. Given it is a write operation, more transparency is needed.
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 with no unnecessary words. It is maximally concise while still conveying the core purpose.
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 annotations, no output schema, and minimal description, the tool lacks sufficient context. It does not cover optional parameters, return values, error scenarios, or any prerequisites, making it incomplete for an agent to use confidently.
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 0%, and the description does not explain any of the five parameters. While recordId and message might be inferred, parameters like confirm, directory, and targetOrg are unexplained, leaving significant ambiguity.
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 ('Post') and resource ('Chatter feed item to a Salesforce record feed'), clearly indicating what the tool does. It distinguishes from sibling sf_chatter_post_to_group by explicitly mentioning 'record feed', 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 implies usage for posting to record feeds rather than group feeds, which differentiates from sf_chatter_post_to_group, but it does not explicitly state when to use this tool or mention alternatives. The guidance is implied by the wording, not stated.
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?
With no annotations, the description must disclose behavioral traits, but it does not mention required permissions, asynchronous nature, potential side effects, or failure behavior. For a tool that executes batch code, this is a significant transparency gap.
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 with no wasted words. It conveys the core action and method efficiently.
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?
For a tool with 5 parameters, no annotations, and no output schema, the description is too sparse. It covers the main purpose but omits parameter behavior, prerequisites, and return value expectations, leaving the agent underinformed.
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 0% and the description provides no parameter details. It implies 'batchClassName' exists but leaves 'confirm', 'directory', 'scopeSize', and 'targetOrg' completely unexplained, forcing the agent to guess their 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 uses a specific verb ('Run') and resource ('Apex batch class'), and uniquely identifies the mechanism ('via Database.executeBatch'). The word 'immediately' differentiates it from sibling scheduling tools like sf_schedule_apex_job.
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?
'Immediately' implies this is for immediate execution rather than scheduled, but the description does not explicitly mention alternatives or when not to use this tool. It provides implied usage context without exclusionary guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the scope (single user, up to 200 records) but does not describe return format, side effects, error handling, or explicitly confirm the operation is read-only. The word 'Check' implies safety but does not confirm it.
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 sentence, front-loaded with the verb 'Check', and contains no filler or redundant information. It earns its place with the specific access types and the record limit.
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?
For a tool with 4 parameters and no output schema, the description is under-specified. It does not explain what the tool returns or the roles of directory and targetOrg. This leaves an agent with insufficient context to invoke the tool correctly, especially in multi-org scenarios.
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 0%, so the description must compensate for the missing parameter details. It only hints at 'single user' (userId) and '200 records' (recordIds), leaving directory and targetOrg unexplained. Agents may not know how to populate these optional 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 states it 'Check read/edit/delete/transfer access for a single user across up to 200 records.' This uses a specific verb and resource, and clearly distinguishes from the sibling tool sf_get_user_object_create_access, which is about object-level access rather than record-level.
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 vs alternatives such as sf_get_user_object_create_access. The description implies record-level access but does not mention exclusions, prerequisites, or alternative tool selection criteria.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but does not disclose whether the operation is read-only, what it returns (e.g., boolean), any required permissions, or error behavior. This is similar to the 'Update shared drive settings' example, which also got a 2 for not explaining 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 a single, concise sentence that immediately states the tool's purpose. It is front-loaded with the action and resource, with no unnecessary words.
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 lack of annotations and output schema, the description is quite sparse. It does not mention the return value (likely a boolean), any required setup, or how the result is presented. The tool is simple, but for an agent to invoke it correctly, more context on behavior and constraints would be needed.
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 0%, so the description must compensate for parameter explanation. It mentions 'field' and 'object', which map to fieldName and objectName, but gives no details about the other parameters like directory and targetOrg, nor does it explain their meaning or required format. Thus it 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 'Determine whether a Salesforce field is nillable on a specific object' uses a specific verb ('determine'), identifies the resource (Salesforce field) and the condition (nillable on a specific object). It clearly distinguishes this from sibling tools like sf_describe_object or sf_query_org, which are broader or data-focused.
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 explicit guidance on when to use this tool versus alternatives, such as using sf_describe_object to inspect field properties. It also lacks any context on prerequisites (e.g., needing objectName/fieldName to exist) or scenarios where this tool is preferred.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It indicates a destructive mutation but does not mention irreversibility, required permissions, confirmation behavior, or consequences of removing non-existent permission sets. Only a terse action statement is given.
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, direct sentence with no filler or redundant content. It is front-loaded and concise, earning every word.
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 has 5 parameters, no output schema, and no annotations. The description is severely underspecified for a Salesforce operation, lacking details on how to identify the user, specify the org, or handle confirmation. It is not complete enough for reliable tool invocation.
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 0%, and the description does not compensate. It vaguely refers to 'permission sets' which maps to the required parameter 'permissionSetNames', but leaves the other four parameters (confirm, directory, targetOrg, onBehalfOfUser) completely unexplained, offering no added meaning 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 clearly states the verb 'remove' and the resource 'permission sets from a user in Salesforce'. It distinguishes from sibling tools like assigning permission sets and removing permission set groups, making the tool's specific function unambiguous.
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, nor does it mention prerequisites or context such as target organization or user identification. It only states the basic action, leaving the agent without direction on appropriate invocation.
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?
With no annotations provided, the description must disclose behavioral traits itself, but it only states the action without describing side effects, waiting behavior, session implications, or error handling. For a navigation tool, key details like page load completion and session state changes are missing.
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 with no redundant words. It efficiently communicates the core action and object, making it excellent in terms of conciseness and 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?
Given the tool has 5 parameters, no output schema, and no annotations, the description is too sparse to be complete. It lacks information about session handling, wait conditions, timeout usage, and how navigation fits into the broader UI automation workflow.
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 0%, so the description must compensate. It only hints at 'url' and 'path' but does not explain sessionId, timeoutMs, or waitUntil. The relationship between 'url' and 'path' (alternatives or combined) is also unclear.
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 'Navigate' and identifies the resource as 'the current UI session,' clearly distinguishing it from sibling tools like ui_action or ui_extract. The scope ('to a URL or path') directly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor does it mention prerequisites or exclusions. The tool name and context hint at UI session navigation, but explicit context is 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention side effects, required permissions, idempotency, impact of the 'confirm' parameter, or what happens if the agent is already active. For a mutating operation, this lack of transparency is a significant gap.
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 single sentence, front-loaded with the key action and resource. It is concise with no redundant words. However, it is so brief that it sacrifices necessary detail, which prevents a perfect score.
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 that this is a mutating tool with six parameters, no annotations, and no output schema, the description is notably incomplete. It lacks details on return values, side effects, prerequisites, and the purpose of the confirm flag, making it insufficient for an agent to use safely and correctly.
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 0%, and the description only mentions apiName and version, leaving other parameters (confirm, directory, targetOrg, apiVersion) unexplained. It adds minimal semantic context by indicating that apiName is the identifier and version is optional, but does not compensate for the full parameter set.
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 specifies the action (activate), the resource (Agentforce agent), and the key identification method (API name and optional version). It distinguishes itself from sibling tools like sf_agent_deactivate and sf_agent_create, which serve 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for activating an agent but provides no explicit guidance on when to use this tool versus alternatives, such as when an agent is already active or when to use deactivate. No exclusions, prerequisites, or context are given, so the use case is only implied.
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?
With no annotations, the description must carry the full burden, but it only states the action. It fails to disclose potential side effects (e.g., impact on running processes), reversibility, permission requirements, or the need for confirmation. The 'confirm' parameter hints at a decision point, but nothing is explained.
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 single, front-loaded sentence with no wasted words, earning a high conciseness score. However, it is under-specified for a tool with 5 parameters, so it is not as effective as a slightly longer description with key 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?
Given the tool's moderate complexity (5 parameters, multiple optional params like confirm and targetOrg), the description is far too sparse. It does not explain the purpose of optional parameters, the behavior of deactivation, or expected outcomes. The absence of an output schema and annotations increases the need for more context, which is not provided.
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 0%, so the description must compensate. It only mentions 'API name' which maps to the apiName parameter, but adds no value beyond the parameter name itself. The other parameters (confirm, directory, targetOrg, apiVersion) are completely unexplained.
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 ('Deactivate') and resource ('an Agentforce agent'), and specifies the key identifier ('by API name'). It distinguishes the tool from siblings like sf_agent_activate, which performs the opposite action.
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 deactivate an Agentforce agent—but provides no explicit when/when-not guidance or mention of alternatives. There is no exclusion criteria or context about when this tool is preferred over others.
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?
No annotations are provided, so the description must carry the full behavioral burden. It does disclose the two targeting modes, but fails to mention the 'confirm' parameter's role (likely a confirmation gate), the need for targetOrg or directory, or what happens if both traceFlagId and username are omitted. This leaves key mutation behavior undisclosed.
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?
A single sentence that front-loads the action and scope. It contains no filler or redundant information, making it highly efficient and easy to parse.
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 5 optional parameters, no annotations, and no output schema, this description is insufficient. It does not explain how directory and targetOrg are used, whether confirmation is mandatory, or what constitutes a valid invocation (e.g., requires either traceFlagId or username). The description is too sparse to enable correct use in varied contexts.
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?
With 0% schema description coverage, the description should compensate by explaining parameters. It only alludes to 'TraceFlag id' and 'user', which map to traceFlagId and username, but it does not mention confirm, directory, targetOrg, or the relationship between them. Five optional parameters remain largely unexplained.
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 names the verb 'Disable', the resource 'debug logs', and the two targeting scopes: by TraceFlag id or for all active flags of a user. It distinguishes itself from sibling tools like sf_enable_debug_logs and sf_list_debug_logs.
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 disabling debug logs is desired) but provides no explicit contrast with alternatives like sf_enable_debug_logs or sf_list_debug_logs. There is no when-not-to-use guidance, but the core 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Read', which implies non-destructive behavior, but doesn't mention return format, potential size limits, metadata fields included, or any required context like targetOrg. The description adds little beyond the verb itself.
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, concise sentence that immediately conveys the core function. It is front-loaded and contains no unnecessary words or repetition.
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 minimal for a tool with three parameters and no output schema. It fails to explain what 'directory' and 'targetOrg' mean, and doesn't describe the return structure beyond 'body and metadata'. This leaves significant gaps in understanding how to invoke the tool correctly.
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 0% and the description only references 'logId' without explaining it. The 'directory' and 'targetOrg' parameters are completely undocumented in both schema and description, leaving the agent without guidance on how to fill them 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 the tool reads the body and metadata for a specific Apex debug log id, using a specific verb (read) and resource (debug log). This distinguishes it from sibling tools like sf_list_debug_logs which list logs, and sf_enable_debug_logs/sf_disable_debug_logs which manage logging.
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: use this tool when you have a specific logId and need to retrieve its content. It doesn't explicitly name alternatives or exclusions, but the distinction from listing or enabling/disabling logs is clear from the sibling tool names.
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?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, requires authentication, makes network calls, or has any side effects. The phrase 'Resolve' suggests a lookup but lacks behavioral context such as what happens on failure or whether it modifies state.
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 sentence, front-loaded with the action and resource. It contains no extraneous words and is appropriately sized for the tool's simplicity.
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 has 3 optional parameters, no schema descriptions, no output schema, and no annotations, this minimal description is insufficient. It does not explain the meaning of the parameters, the return value format, or any edge cases. The description only covers the basic purpose, leaving significant gaps 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'target org or default target org', which gives a hint about targetOrg and defaultTargetOrg but does not define them clearly. The 'directory' parameter is entirely unexplained. No parameter semantics are added beyond the 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 clearly states a specific action ('Resolve') and resource ('username and alias for a target org or default target org'). This distinguishes it from sibling tools like sf_list_all_orgs, which lists orgs, and the various access/query tools. 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 usage when needing the username and alias for a specific target org or the default org, but it does not explicitly state when to choose this over alternatives, nor does it mention any exclusions or prerequisites. There is no direct guidance on when not to use it or comparison 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?
With no annotations provided, the description carries the transparency burden. It conveys a safe, read-only listing action and implies temporal ordering with 'recent,' but it does not disclose return format, default limit, pagination, or other behavioral nuances.
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 states the core purpose with no filler or redundant details. It is appropriately concise for a simple listing tool.
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 has 4 parameters, no annotations, and no output schema, yet the description only provides a minimal purpose statement. It lacks essential context about parameter usage, return values, and how it relates to the broader debug log workflow, making it incomplete for reliable invocation.
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 0% and there are 4 parameters, but the description only maps 'target org' to the targetOrg parameter. There is no explanation of limit, username, or directory, leaving the agent without sufficient information to set them 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 identifies the action ('List'), the resource ('Apex debug logs'), and the scope ('from the target org'). It distinguishes this tool from the sibling sf_get_debug_log by using 'list' and 'recent'.
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 like sf_get_debug_log or sf_enable_debug_logs. It does not mention any prerequisites, related tools, or context that would help the agent choose this over siblings.
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?
With no annotations, the description must carry the full burden of behavioral disclosure. It only mentions 'explicit nextRecordsUrl support', which hints at pagination behavior but does not explain whether it automatically pages through results, how maxRecords interacts, or any rate limits or side effects. Significant ambiguity remains about the tool's 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, perfectly front-loaded with the core action and purpose. Every word 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (6 parameters, no output schema, no annotations) and the context of many sibling tools, the description is too sparse. It does not mention return format, pagination semantics (auto vs manual), or the role of directory/targetOrg, leaving critical usage 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?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only clarifies 'nextRecordsUrl', while neglecting pageSize, maxRecords, directory, and targetOrg. The parameter names are somewhat self-evident, but ambiguous ones like 'directory' are not explained.
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 'Run', the resource 'SOQL queries', and the specific aspect 'paginated' with 'explicit nextRecordsUrl support'. This distinguishes it from sibling tools like sf_query_org or sf_search_org, which likely handle non-paginated or search queries.
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 paginated queries and nextRecordsUrl handling, but it does not explicitly say when to prefer this over sf_query_org or other query tools. It lacks direct guidance on alternatives or exclusions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, or return format. It only restates the action without adding contextual depth beyond the basic purpose.
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, focused sentence with no redundant words. It's appropriately front-loaded and concise for its limited scope, making every word earn its place.
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 no annotations, the description should explain the tool's behavior more fully. It omits any explanation of optional parameters and the structure of the returned schema, making it incomplete for a 3-parameter 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 minimal parameter meaning by mentioning 'object name' for objectName, but fails to explain 'directory' and 'targetOrg', which have zero schema coverage and no descriptions. With 0% coverage, the description should compensate but only does so for one 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 the tool describes a Tooling API object schema by object name, using a specific verb and resource. It differentiates from sibling describe tool via the 'Tooling API' qualifier, making the scope 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 provides no explicit usage guidance or exclusions. It doesn't reference alternatives like sf_describe_object for standard objects; usage is inferred only from the 'Tooling API' term, so the intent is clear but not directly stated.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. 'Fetch' implies a read-only operation, but the description does not explicitly state that it is non-destructive, mention permission requirements, or describe behavior for missing classes or errors. Minimal behavioral context is provided.
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 sentence with no superfluous words, placing the action and key target first. It is appropriately sized and front-loaded, earning a high score for conciseness.
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 has three parameters, no annotations, and no output schema, yet the description only covers the basic fetch operation. It does not explain the purpose of directory and targetOrg, the return structure, potential errors, or any limitations, making it under-specified for reliable agent use.
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 0%, so the description must compensate. It explains 'className' implicitly via 'by class name,' but the parameters 'directory' and 'targetOrg' are left entirely unexplained. The description fails to add meaning for two of the three 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 clearly states the action (Fetch), the resource (ApexClass metadata and body), and the method (by class name via Tooling API), effectively distinguishing it from more generic query tools like sf_tooling_query.
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 retrieving a specific ApexClass but provides no explicit guidance on when to use this vs. alternatives such as sf_tooling_query, nor any when-not-to-use conditions. The purpose is clear enough to infer the use case, but exclusions are missing.
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?
With no annotations provided, the description carries the full burden. It indicates a read-only listing behavior but does not disclose return format, pagination, or any dependencies. The behavior is clear at a high level, but lacks 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?
The description is a single, focused sentence with no wasted words. It front-loads the core purpose and is appropriately concise.
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 unexplained directory parameter and the absence of an output schema or annotations, the description is not sufficient for an agent to confidently invoke the tool. It leaves a key parameter ambiguous and says nothing about expected output.
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 mentions 'target org', which adds meaning to the targetOrg parameter, but the directory parameter is completely unexplained. With 0% schema description coverage, the description must compensate, but it only partially does.
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 ('List') and resource ('Tooling API sObject types'), including the scope ('in the target org'). This distinguishes it from sibling tools like sf_tooling_query and sf_tooling_describe_object.
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 such as sf_tooling_query or sf_tooling_describe_object. The description implies its use for discovering available sObject types, but does not explicitly state this or any 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?
No annotations are provided, so the description carries the full burden. It discloses the key non-destructive behavior ('without committing changes'), but does not explain what validation entails—whether tests run, how conflicts are handled, or what output to expect. This is more than a tautology but lacks operational detail.
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 single, clear, front-loaded sentence with no filler words. It is concise and readable, though it is arguably too brief for a tool with 9 parameters and no additional documentation.
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 (9 parameters, no output schema, no annotations), the description is insufficient. It establishes the core purpose but omits prerequisites, relationship to sf_deploy_metadata, expected outputs, and any guidance on parameter usage, making it incomplete for safe autonomous invocation.
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 0%, and the description gives no information about any of the 9 parameters. Parameters like manifest, sourceDir, tests, targetOrg, and ignoreConflicts are entirely unexplained, leaving the agent without semantic guidance beyond their 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 uses a specific verb ('Validate') and clear resource ('Salesforce metadata deployment'), and adds the critical qualifier 'without committing changes.' This clearly distinguishes it from the sibling tool sf_deploy_metadata, which performs an actual 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 phrase 'without committing changes' implies this is a dry-run validation, useful before an actual deployment. However, it does not explicitly name sf_deploy_metadata as the alternative for committing changes, nor does it state when validation should be preferred.
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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals the source repository (forcedotcom/sf-skills), but does not mention external network access, authentication requirements, error behavior, or return format. This is insufficient for a tool without annotation support.
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, focused sentence that directly states the tool's purpose. It is appropriately sized and front-loaded, with no unnecessary words or repetition of schema details.
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 simple fetch operation, the description provides a baseline understanding, but it is incomplete. It does not explain what includeReferences does or what the tool returns (e.g., raw markdown content, path, etc.), especially since no output schema exists.
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 0%, so the description must compensate. It does not mention either parameter (skillName or includeReferences). While skillName is somewhat inferable from the tool name, includeReferences remains entirely unexplained, leaving ambiguity.
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 fetches a Salesforce skill definition (SKILL.md) from a specific repository (forcedotcom/sf-skills). The verb 'Fetch' and resource are specific, distinguishing it from sibling tools like sf_skills_search (search) and sf_skills_list_domains (list domains).
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 when a specific skill name is known, but it does not explicitly compare with alternatives like sf_skills_search or sf_skills_list_domains. There is no mention of when to use this versus searching, so guidance is only implied by the verb 'Fetch'.
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?
No annotations are provided, so the description carries the full burden. 'Stop and dispose' indicates a destructive action, but it does not disclose side effects, idempotency, behavior with invalid session IDs, or impact on associated resources. This lacks transparency for a terminating operation.
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, concise sentence that is front-loaded with the action and target. Every word contributes meaning; there is no fluff or redundancy, making it an appropriately sized description.
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 stop operation, the description covers the basic purpose. However, it omits details such as return values, error behavior, prerequisites (e.g., session must be active), and whether the operation is idempotent. Given the low complexity and lack of output schema, this is minimally adequate but not 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?
The schema has one parameter, sessionId, with 0% description coverage. The description does not mention this parameter, add meaning beyond the name/type, or clarify whether it is required. The schema's optional flag is ambiguous, and the description fails to compensate for the zero 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 uses the specific verb 'Stop and dispose' and clearly names the resource 'Playwright UI session'. It distinguishes itself from sibling tools like ui_session_start and ui_navigate by indicating it ends a session.
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—it is the counterpart to ui_session_start—but does not explicitly state when to use it or provide alternatives. No exclusions or conditions are mentioned, leaving usage to be inferred from 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only operation by using 'list' and 'authenticated', but does not explicitly state that it is safe, non-mutating, or what happens if no orgs are authenticated. Minimal context is given.
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, clear sentence with no unnecessary words. It front-loads the action and target, making it easy to parse.
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 is complete for a simple listing tool but lacks detail about the output format (e.g., list of aliases, usernames, or IDs) and any prerequisites such as requiring a Salesforce CLI login. Since there is no output schema, additional context about return values would improve completeness.
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 the schema fully covers them. The description does not need to add parameter semantics. With no parameters, the baseline score of 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 clearly states the tool's function: listing authenticated Salesforce orgs from Salesforce CLI. The verb 'List' and specific resource 'authenticated Salesforce orgs' distinguish it from other list-related siblings like sf_list_metadata or sf_package_list.
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 usage guidance is provided. It does not state when to use this tool versus alternatives, nor does it mention any preconditions or exclusions. The context is implied by the name but not explicitly stated.
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?
With no annotations provided, the description carries full responsibility for explaining behavior. It mentions 'remote' implying network calls, and 'Search' implies read-only, but it does not state whether any data is modified, whether there are rate limits, or what exactly gets returned. 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 a single, front-loaded sentence that communicates the core purpose and key benefit. There is no wasted text or unnecessary 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?
Given three parameters, no output schema, and no annotations, the description is too sparse. It does not explain how to construct or limit a query, what includeContentSearch does, or what the return format looks like. The agent would likely need additional information to invoke this tool correctly for anything beyond a trivial default query.
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 0%, and the description does not explain any of the three parameters (query, limit, includeContentSearch). The names are somewhat self-explanatory, but the description adds no additional meaning, forcing the agent to rely on schema field names 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 a specific verb ('Search'), the resource ('remote Salesforce skills from forcedotcom/sf-skills'), and an important distinction from local operations ('without local clone'). This effectively differentiates it from the many sibling tools that operate on Salesforce org 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 phrase 'without local clone' provides useful guidance on when to use this tool—instead of cloning the repository locally. However, it does not explicitly mention alternatives like sf_skills_get or sf_skills_list_domains, 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.

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-MCP-Pro MCP server](https://glama.ai/mcp/servers/adamcmyhre/Salesforce-MCP-Pro/badges/card.svg)](https://glama.ai/mcp/servers/adamcmyhre/Salesforce-MCP-Pro)

Score Badge

Copy to your README.md:

[![Salesforce-MCP-Pro MCP server](https://glama.ai/mcp/servers/adamcmyhre/Salesforce-MCP-Pro/badges/score.svg)](https://glama.ai/mcp/servers/adamcmyhre/Salesforce-MCP-Pro)

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/adamcmyhre/Salesforce-MCP-Pro'

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