list_mdf_objects

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

With no annotations, the description carries the burden. It explains categories and general behavior (listing all MDF objects) but does not disclose authentication requirements or side effects. It adds value beyond the schema by explaining the filter purpose but lacks 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.

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

The description is appropriately sized: three sentences front-load the purpose, then detail categories, then add context. It is efficient but could omit the last sentence without losing essential information.

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

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

Given moderate complexity (5 params, no required) and existence of an output schema, the description covers the main parameter and context but omits other parameters. It is adequate for basic use but not fully 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?

Schema description coverage is low (20%). The description adds meaning for the 'category' parameter by defining 'custom', 'standard', 'all' and mapping them to object types. However, it ignores other parameters (data_center, name_search, auth_user_id, auth_password), leaving them unexplained beyond the schema.

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

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

The description clearly states 'List all MDF objects configured in the SF instance,' specifying the verb (list) and resource (MDF objects). It differentiates from siblings like get_mdf_object_definition by focusing on the full set and provides a category filter.

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

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

The description provides clear usage context: it inventories MDF objects, especially in instances with many custom objects. It implies when to use (to explore available objects) but does not explicitly mention when not to use or alternatives, though sibling tools serve different purposes.

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