cap_table_clear_cap_table_stakeholdersClearCapTableStakeholders deletes every stakeholder of a company in a single DB-level operation. Used by the "replace cap table" import flow.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | Yes | UUID value wrapper. |
| Name | Required | Description | Default |
|---|---|---|---|
| deletedCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states the operation is destructive ('deletes every stakeholder'), but the annotations declare destructiveHint false. This is a direct contradiction, making the behavioral transparency misleading. The description adds the important detail of 'single DB-level operation' but the annotation conflict overrides that.
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, each adding value: the first defines the exact action and scope, the second explains its intended usage. No filler or redundant content.
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?
The description covers the essential aspects: what it does, scope, and use case. It does not explain irreversibility, permissions, or downstream effects, but given the simple single-parameter signature and presence of an output schema, this is mostly adequate. The annotation contradiction reduces trust but not completeness per se.
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% with companyId documented as 'UUID value wrapper.' The description adds no additional parameter semantics beyond what the schema provides. Baseline of 3 is appropriate because the schema fully covers the single parameter.
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 uses a specific verb 'deletes' and clearly identifies the resource 'every stakeholder of a company'. It distinguishes itself from sibling tools like cap_table_delete_cap_table_stakeholder by emphasizing the bulk, all-stakeholders scope and single DB-level operation.
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?
It states a clear use case: 'Used by the "replace cap table" import flow.' This gives context for when to invoke this tool versus the singular delete alternative. However, it does not explicitly list exclusions or alternative tools for partial deletes, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Multiple tool pairs are nearly identical (formation_extract_cap_table / formation_extract_cap_table_ocr; formation_start_formation / formation_create_formation), and several tools lack descriptions, making selection ambiguous. The scale of 202 tools with overlapping summaries (e.g., multiple cap-table summary tools) compounds the confusion.
Dominant snake_case `module_verb_noun` pattern, but with notable deviations: `captable_send_safe_for_signature` uses an inconsistent abbreviation, `check_company_name_availability` lacks a module prefix, and `get_list_` vs `list_` prefixes are mixed. Readable but not fully consistent.
202 tools is far beyond any reasonable surface for a single server, even a broad platform. The sheer number overwhelms and makes tool discovery impractical; many tools are peripheral (ads metrics) to the core formation purpose.
The domain appears well covered: formation flows, cap-table lifecycle (import, close, simulate), accounting (journal entries, periods, schedules), cards, documents, and transactions all have CRUD or lifecycle operations. Minor gaps exist (e.g., no card deletion, no counterparty creation), but they are unlikely to cause dead ends.