Server Quality Checklist

Tool Scores

• salesforce_manage_objectA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses key behavioral traits: 'Changes affect metadata' (important for Salesforce administrators) and 'require proper permissions' (security context). However, it doesn't mention potential side effects, rate limits, or what happens when creating/updating fails. The description doesn't contradict annotations since none exist.

  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 appropriately sized with 4 sentences: purpose statement, bullet points for create/update operations, examples, and important note. It's front-loaded with the core purpose. Minor improvement could be merging the bullet points into the first sentence for even tighter structure.

  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 metadata mutation tool with 9 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the core purpose, examples, and permission requirements, but lacks information about return values, error conditions, or detailed behavioral expectations. The 100% schema coverage helps, but more behavioral context would be beneficial.

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

  Parameters3/5

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

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

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Create new custom objects or modify existing ones in Salesforce' with specific verbs (create/update) and resources (custom objects). It distinguishes from siblings like salesforce_manage_field (fields vs objects) and salesforce_describe_object (read vs write).

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

  Usage Guidelines3/5

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

  The description implies usage context through examples ('Create Customer_Feedback__c object, Update object sharing settings') and mentions permissions, but doesn't explicitly state when to use this tool versus alternatives like salesforce_manage_field or salesforce_dml_records. No explicit exclusions or alternative recommendations are provided.

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

• salesforce_search_objectsA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the search functionality. It does not disclose behavioral traits such as permissions needed, rate limits, pagination, or what happens on no matches. This is a significant gap for a search tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is front-loaded with the core purpose, followed by illustrative examples. Every sentence earns its place by clarifying the tool's behavior without redundancy. It is appropriately sized and efficient.

  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 no annotations and no output schema, the description is adequate for a simple search tool but incomplete. It explains what the tool does but lacks details on return values, error handling, or advanced usage. It meets minimum viability but has clear gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents the 'searchPattern' parameter. The description adds value with examples ('Account' vs 'Account Coverage'), but does not provide additional syntax or format details beyond what the schema implies. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the specific action ('Search for Salesforce standard and custom objects') and resource ('by name pattern'), distinguishing it from siblings like 'salesforce_describe_object' (describe single object) and 'salesforce_search_all' (search records). The examples reinforce the scope.

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

  Usage Guidelines4/5

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

  The description implies usage context through examples (e.g., finding 'Account' vs 'AccountHistory'), but does not explicitly state when to use this tool versus alternatives like 'salesforce_search_all' or 'salesforce_query_records'. It provides clear intent but lacks explicit comparison.

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

• salesforce_search_allA
  3.8/5.0
  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 of behavioral disclosure. It adds some context, such as support for wildcards, object-specific clauses, and WITH clauses, but does not cover critical aspects like rate limits, authentication needs, error handling, or what the output looks like (since no output schema exists). It partially compensates but leaves gaps for a complex search 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 well-structured with a clear purpose statement, examples, and notes, but it is lengthy due to detailed examples. Every sentence earns its place by clarifying usage, though it could be more front-loaded; the purpose is clear, but the bulk is in examples, which are helpful but add verbosity.

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

  Completeness3/5

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

  Given the tool's complexity (6 parameters, no annotations, no output schema), the description is moderately complete. It covers input semantics and usage examples but lacks output details, error handling, and behavioral constraints like performance or limits. It provides enough for basic use but falls short for full agent guidance in a production environment.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds value by providing examples that illustrate parameter usage (e.g., 'objects' with nested properties, 'withClauses' types) and notes on wildcards and access filtering ('updateable' and 'viewable'), enhancing understanding beyond the schema's technical definitions. This elevates the score above baseline.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Search across multiple Salesforce objects using SOSL (Salesforce Object Search Language).' It specifies the verb ('search'), resource ('multiple Salesforce objects'), and technology ('SOSL'), distinguishing it from sibling tools like 'salesforce_query_records' (likely SOQL) and 'salesforce_search_objects' (possibly simpler). This is specific and avoids tautology.

  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 through examples and notes, such as wildcard support and object-specific clauses, but does not explicitly state when to use this tool versus alternatives like 'salesforce_query_records' or 'salesforce_search_objects'. It provides context for advanced searches but lacks clear guidance on tool selection among siblings.

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

• salesforce_describe_objectA
  3.9/5.0
  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 discloses that the tool retrieves metadata (not data) and includes examples of what information is returned (fields, relationships, properties). However, it lacks details on permissions required, rate limits, error conditions, or the structure/format of the returned metadata, which are important for a tool with no output schema.

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

  Conciseness5/5

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

  The description is front-loaded with the core purpose in the first sentence, followed by illustrative examples that reinforce understanding without redundancy. Both sentences earn their place by enhancing clarity and usability, with no wasted words.

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

  Completeness3/5

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

  For a tool with no annotations and no output schema, the description adequately covers the purpose and basic usage but lacks sufficient behavioral context (e.g., authentication needs, response format, error handling). Given the complexity of Salesforce metadata and the absence of structured output documentation, more detail would improve completeness.

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

  Parameters3/5

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

  The input schema has 100% description coverage, clearly documenting the single required parameter 'objectName'. The description adds value by providing examples ('Account', 'Case', 'Custom_Object__c') that clarify valid inputs beyond the schema's generic description, but does not explain parameter behavior or constraints further.

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

  Purpose5/5

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

  The description clearly states the specific action ('Get detailed schema metadata') and resource ('any Salesforce object'), with concrete examples ('Account', 'Case') that illustrate the scope. It distinguishes this read-only metadata tool from sibling tools that perform DML operations, manage objects/fields, or query/search records.

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

  Usage Guidelines4/5

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

  The description implies usage for obtaining schema metadata, which differentiates it from data-oriented siblings like salesforce_query_records or salesforce_dml_records. However, it does not explicitly state when to use this tool versus alternatives like salesforce_search_objects or provide exclusions (e.g., not for data retrieval).

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

• salesforce_query_recordsA
  4/5.0
  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 of behavioral disclosure. It does well by specifying the query language (SOQL), relationship query capabilities, and syntax rules for custom relationships. However, it doesn't mention important behavioral aspects like pagination, rate limits, authentication requirements, error handling, or what happens when queries return large result sets. The examples are helpful but don't cover all behavioral traits.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded with the core purpose statement. The examples are well-organized and directly relevant to understanding the tool's capabilities. While comprehensive, some information could be more concise - the relationship syntax rules might be condensed. Every sentence earns its place by clarifying SOQL query patterns.

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

  Completeness3/5

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

  Given the tool's complexity (SOQL queries with relationships, 5 parameters) and the absence of both annotations and output schema, the description does a decent job but has gaps. It covers the core functionality and parameter usage well through examples, but doesn't address return format, error conditions, performance considerations, or how results are structured (especially for nested relationship queries). For a query tool with no output schema, more information about response structure would be helpful.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds significant value through the four detailed examples that show how parameters work together in practice, especially for relationship queries. It clarifies dot notation for parent relationships, subqueries for child relationships, and the '__r' suffix for custom relationships - all semantic details beyond what the schema provides. However, it doesn't cover all parameters equally (orderBy and limit get less attention).

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

  Purpose5/5

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

  The description explicitly states 'Query records from any Salesforce object using SOQL, including relationship queries' - this is a specific verb ('Query') with clear resource ('records from any Salesforce object') and distinguishes from siblings like salesforce_dml_records (for data manipulation) and salesforce_search_all/search_objects (for search operations). The mention of SOQL and relationship queries further clarifies the technical approach.

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

  Usage Guidelines4/5

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

  The description provides clear context about when to use this tool (for SOQL queries with relationship support) and the examples demonstrate various query patterns. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the sibling tools (like when to use salesforce_search_all instead). The guidance is strong but lacks explicit exclusion criteria.

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

• salesforce_dml_recordsA
  4.1/5.0
  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 of behavioral disclosure. It correctly identifies this as a data manipulation tool with destructive operations (delete) and mutation operations (insert, update, upsert). However, it lacks critical behavioral details like permission requirements, transaction boundaries, error handling, or rate limits that would be important for an agent to use this tool safely.

  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 efficiently structured with a clear opening statement followed by bullet points for operation types and specific examples. Every sentence adds value, with no redundant information. The bullet format makes it easy to scan and understand quickly.

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

  Completeness3/5

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

  For a complex DML tool with no annotations and no output schema, the description provides adequate basic information about operations but lacks important context. Missing elements include: expected return format, error behavior, permission requirements, and transactional guarantees. The examples help but don't fully compensate for the lack of structured behavioral metadata.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the schema already documents all parameters well. The description adds meaningful context by explaining what each operation type does and providing concrete examples that help interpret the 'records' parameter content. However, it doesn't fully explain the structure of records objects or externalIdField usage beyond mentioning it's for upsert.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 performs 'data manipulation operations on Salesforce records' and lists specific operations (insert, update, delete, upsert) with brief explanations. It distinguishes from sibling tools like salesforce_query_records (read-only) and salesforce_describe_object (metadata) by focusing on 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 Guidelines4/5

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

  The description provides clear context for when to use each operation type (e.g., 'update: Modify existing records (requires Id)') and includes examples. However, it doesn't explicitly state when NOT to use this tool versus alternatives like salesforce_manage_object for object-level operations or provide prerequisites beyond ID requirements.

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

• salesforce_manage_fieldA
  4.2/5.0
  Behavior4/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 effectively communicates that this is a metadata mutation tool ('create new custom fields or modify existing fields'), specifies that 'changes affect metadata,' and notes permission requirements. It doesn't mention rate limits, side effects on existing data, or whether operations are reversible, but covers the essential safety and scope aspects for a metadata 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 efficiently structured with a clear opening statement followed by bullet-point categorization and specific examples. Every sentence earns its place by providing distinct value: the first sentence states the core purpose, the bullets organize parameter concepts, the examples illustrate use cases, and the note adds critical behavioral context. No wasted words.

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

  Completeness4/5

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

  For a complex metadata mutation tool with 17 parameters and no annotations or output schema, the description does well by covering purpose, scope, permission requirements, and parameter categories. It could be more complete by explicitly mentioning that this tool doesn't handle data values (unlike salesforce_dml_records) or describing typical response formats, but it provides sufficient context for an agent to understand the tool's role and basic usage.

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

  Parameters3/5

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

  The schema description coverage is 100%, so the schema already documents all 17 parameters thoroughly. The description adds some value by categorizing parameters into 'Field Types,' 'Properties,' and 'Relationships,' which helps conceptual organization, but doesn't provide additional syntax, format, or constraint details beyond what's in the schema. This meets the baseline for high schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with specific verbs ('create new custom fields or modify existing fields') and identifies the resource ('any Salesforce object'). It distinguishes this tool from siblings like salesforce_dml_records (data manipulation) and salesforce_describe_object (metadata inspection) by focusing on field-level metadata management.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool through examples ('Add Rating__c picklist to Account, Create Account lookup on Custom Object') and notes about prerequisites ('require proper permissions'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the context implies it's for field metadata rather than data operations.

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