list_supported_artifacts

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

The readOnlyHint=true annotation already declares this as a read-only operation, and the description aligns ('list'). The description adds value by specifying this is scoped to 'Local sync' capabilities and that it returns both artifact types AND field-sync mappings, which is useful behavioral detail beyond the annotation. No contradiction.

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

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

The description is a single, information-dense sentence that conveys scope (local sync), resource (artifact types/tables), operations (pull/push), and the field-sync detail in one line. There's no wasted wording, and it's front-loaded with the 'Local sync' qualifier which is the most important disambiguator.

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

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

Given the tool has no parameters, no output schema, and readOnly annotations covering the safety profile, the description provides adequate completeness. It covers what data is returned (artifact types + syncing fields), but doesn't mention return format, pagination, or whether output varies by instance. For a capability-discovery tool this is reasonably complete.

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

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

The tool has 0 parameters, so there's nothing for the description to elaborate on. The description's mention of returning 'which fields sync for each' artifact type provides useful context about what the response will contain, effectively substituting for lacking an output schema. A baseline of 4 is appropriate for a zero-parameter read tool where the description clarifies the response content.

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

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

The description clearly states what the tool does: lists artifact types (tables) supporting pull/push to local files and which fields sync for each. The verb 'list' plus the resource 'supported_artifacts' with the 'local sync' context makes the purpose clear. It distinguishes from siblings like pull_artifact/push_artifact by focusing on the capabilities listing rather than the operation itself.

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

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

The description conveys that this is used in the 'Local sync' context, which implies it's meant to be called before pull/push operations to discover what's supported. However, it doesn't explicitly state when to use this vs alternatives like sync_status or pull_artifact, nor does it give explicit when-not guidance. The context is implied but not fully explicit.

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