get_creditors

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 clarify an important nuance: the creditor list includes creditors even if they did not file a claim. However, it doesn't explicitly state that this is a read-only operation or mention cost implications for live PACER refresh, though the schema does cover the latter.

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 two sentences long, front-loaded with the core purpose and immediately followed by a differentiation from a sibling tool. There is zero redundancy; every phrase adds value.

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 straightforward retrieval tool, the description is well-rounded: it defines the data source, inclusion criteria, and relationship to get_claims. The absence of an output schema is mitigated by the clear 'list' indication. Minor omissions like pagination details are not critical, given the tool's simplicity.

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 all parameters are already well-documented in the schema. The main description adds no parameter-specific information, so the baseline score of 3 is appropriate.

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 opens with a specific verb ('Get') and resource ('creditor list'), then clearly defines the scope: all creditors scheduled in Schedules D/E/F, whether or not they filed a proof of claim. It also explicitly contrasts itself with the sibling tool get_claims, making the tool's purpose unmistakable.

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 directly names get_claims as an alternative and explains the key distinction (scheduled creditors vs. filed proofs of claim). This gives explicit when-to-use guidance. Additionally, the schema parameter descriptions recommend using list_courts and find_cases when unsure, providing further orientation.

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