meta get entity configuration

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior, so the bar for additional value is lower. The description adds meaningful context beyond annotations: 'never creates, changes or retries the entity' and the caveat that missing or normalized fields must be inspected before claiming an exact match. This helps an agent understand result reliability without contradicting the annotations.

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

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

Two sentences, front-loaded with the core action and read-only guarantee, followed by the reconciliation caveat. Every sentence earns its place and there is no redundant restatement of the title or schema.

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 a fully described input schema, an output schema, and annotations covering safety and open-world behavior, the description is complete enough. It supplies the reconciliation purpose and the critical caveat about missing/normalized fields, which are the only non-obvious details an agent needs to use the tool correctly.

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 100%, so the input schema fully explains adAccountId, entityId, and fields. The description adds little per-parameter meaning, though it reinforces that fields are read during reconciliation and that normalized/missing values are possible. Baseline 3 is appropriate because the schema carries the param-semantics load.

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 states a specific verb ('Read'), a resource ('a specific entity in its ad account'), and a purpose ('reconciliation'), which clearly conveys what the tool does. It differentiates itself from the many list/get siblings by focusing on a single entity by ID and fields, though it does not explicitly name an alternative to distinguish from.

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 implies usage for reconciliation and explicitly warns against expecting mutation or retries, but it does not state when to prefer this tool over siblings like meta_get_campaigns or meta_get_adset_configuration. There is no explicit when-to-use/when-not-to-use guidance or mention of alternatives, leaving selection partly to inference.

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