pdf_template_config_get

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. The description honestly reveals that this is not purely a read operation — it may create a default config on first call ('Creates a default config if none exists'). This is a valuable behavioral disclosure that prevents surprise. However, it doesn't specify auth requirements or what happens with the companyId override parameter.

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, both informative. The first sentence states purpose and return contents; the second reveals the important create-on-miss side effect. No wasted words. Slightly could be improved by front-loading even more, but it's already tight.

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?

For a read-style config getter with a single optional param and no output schema, the description is reasonably complete. It lists what fields are returned, states the scoping (current company), and discloses the side effect. Gaps: no mention of auth requirements, and no details about what a default config looks like when created, but for a getter this is adequate.

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 coverage is 100% with only one optional parameter (companyId). The description explains the companyId semantics implicitly through 'current company' and the schema states 'overrides configured default.' Since the description covers 'current company' context and the schema fully documents companyId, the combination is adequate. With only one well-documented parameter, the burden is low.

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 the verb ('Get'), resource ('PDF template configuration'), and scope ('for the current company'). It enumerates exactly what data is returned (template slug, primary color, font, logo/bank info visibility, footer text, custom CSS), which distinguishes it well from siblings like pdf_template_config_update (mutator) and pdf_template_config_templates (listing available templates).

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 establishes clear context: this retrieves settings for the current company, and notably mentions 'Creates a default config if none exists' — a critical side-effect behavior an agent must know. It doesn't explicitly state when to prefer this over siblings, but the read-vs-write distinction from pdf_template_config_update is self-evident. A small gap: no explicit exclusion of when not to use it.

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