Ten ways to fund a small acquisition, and what acquisition funders say about themselves.
Scored across 4 tools
The four tools separate cleanly: list_structures covers funding arrangements, list_funding_providers covers external lenders, get_structure retrieves one structure by id, and get_posture provides referral guidance. There is slight potential confusion between list_structures and list_funding_providers since both center on funding, but their descriptions make the distinction clear.
All tool names follow the same verb_noun pattern: get_ for singular lookups and list_ for collection lookups. This is a consistent and predictable convention across the entire set.
Four tools is well-scoped for a focused reference server about acquisition funding. Each tool covers a distinct function without unnecessary bloat, and the count fits the domain naturally.
The set covers the core read-only workflows: listing and retrieving funding structures, listing funding providers, and accessing referral posture. A get_funding_provider detail tool might be a minor addition, but the list tool appears to already expose the needed facts.
ZeroAcquire's referral posture. Read this before repeating anything from list_funding_providers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral context. It implies a read operation but does not state whether it is read-only, what it returns, whether it has side effects, or why reading it is required before repeating funding provider info. The phrase 'Read this' hints at a prerequisite but leaves the actual behavior and output opaque.
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 very short and each sentence earns its place: one identifies the resource and one gives a usage directive. It is front-loaded and avoids verbiage, though the first sentence is a noun fragment rather than a clear declarative statement.
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 0-parameter tool with no output schema and no annotations, the description still leaves major gaps: what is 'referral posture', what does the returned data look like, and why must it be read before repeating list_funding_providers? The description gives a context cue but not enough for an agent to fully understand the tool's role or result.
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?
The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to add about parameter meanings. A zero-parameter tool gets a baseline of 4, and the description appropriately does not attempt to describe parameters.
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 identifies the tool as 'ZeroAcquire's referral posture', which is a specific noun phrase, but does not define what a referral posture is or what action the tool performs beyond the name 'get_posture'. It clearly points to a resource but lacks a concrete verb+resource statement, and it only weakly distinguishes itself from siblings via the word 'posture'.
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 gives explicit guidance: 'Read this before repeating anything from list_funding_providers.' This tells the agent when to invoke this tool and references a specific sibling as the alternative to consult after reading. However, it does not explain when to use get_posture in other contexts or 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.
One funding structure in full, by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | e.g. seller-note, earnout, lease-to-own |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'in full' which suggests the response includes all fields of the structure, but it doesn't disclose whether the tool is read-only, whether it can return null/404 for unknown ids, whether it requires any special permissions, or what the response shape looks like. For a simple get-by-id tool, this is a moderate gap.
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 a single, compact sentence that front-loads the key information: what is returned, the scope ('one'), and the lookup key ('by id'). No wasted words.
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 simple get-by-id tool with one parameter and no output schema, the description is mostly adequate. However, with no annotations and no output schema, it would benefit from stating what happens when the id is not found (e.g., returns null or 404) and confirming the operation is read-only. The sibling context (list_structures) helps, but the description alone leaves a few minor gaps.
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%: the only parameter 'id' is described with examples ('seller-note, earnout, lease-to-own'). The description adds the context that the id identifies a funding structure, but the schema already conveys that. Baseline 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 'One funding structure in full, by id' clearly identifies the verb (get), the resource (funding structure), and the retrieval mechanism (by id). It distinguishes itself from list_structures (which presumably lists multiple structures) and from get_posture (a different resource). However, it doesn't explicitly name the sibling it is not, so it doesn't fully earn a 5.
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: call this when you need a single funding structure by its id, and use list_structures when you need multiple. It doesn't explicitly state when to prefer get_posture or list_funding_providers, but the resource names make the context reasonably clear. No explicit exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What acquisition funding providers publish about themselves, each fact carrying the URL it was read from and the date. Includes whether they are still accepting applications.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: each fact includes the URL and date of origin, and it explicitly notes whether providers are still accepting applications. This goes beyond a simple 'list' and gives the agent insight into the data's provenance and current status. It does not mention ordering or pagination, but for a parameterless list, this is adequate.
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 a single, well-structured sentence. It front-loads the core purpose ('What acquisition funding providers publish about themselves'), then adds detail about the facts' provenance and the acceptance status. No wasted words; every clause 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?
Given the tool has no parameters, no output schema, and no annotations, the description provides a reasonable overview of what is returned. It explains the nature of the facts (URL and date) and includes the acceptance status. It does not specify pagination, ordering, or limits, but for a simple list tool, this is likely sufficient. The absence of an output schema means the description must convey the return structure, which it partially does by describing the facts.
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?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meaning since there are none. The schema coverage is 100% (no properties), and the description's content about the output is sufficient.
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 tool's function: it lists acquisition funding providers and the facts they publish, with each fact including the source URL and date, plus whether they accept applications. This is a specific verb (list) with a resource (funding providers) and distinct output content, distinguishing it from siblings like get_posture and get_structure which are unrelated.
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?
There is no explicit guidance on when to use this tool versus alternatives. However, the purpose is self-evident from the name and description, and the siblings are clearly different domains (posture, structure). The usage is implied but not articulated, so a score of 3 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the ten ways to fund a small acquisition, with what each requires, what the seller must accept, what rules it out and what it costs the buyer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. 'List' implies a read-only operation, and the description explains what the returned information contains per structure. It does not explicitly state absence of side effects, but for a parameter-less list operation this is a minor omission rather than a serious gap.
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?
One dense sentence states the exact scope and the four dimensions covered for each item. It is front-loaded with the action and resource, and every clause adds information. Nothing extraneous is present.
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?
Since there is no output schema, the description must convey what the tool returns on its ownhj. It does so by enumerating the per-item details (requirements, seller acceptance, disqualifiers, buyer cost). The only small gaps are the lack of an explicit return format and confirmation that exactly ten structures will always be listed, but the description is still complete enough for an agent to select and invoke the tool.
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?
The tool has zero parameters abb. The schema already shows additionalProperties: false with no properties, so there is no parameter ambiguity. Baseline for a no-parameter tool is 4, and the description correctly focuses on the output instead of inventing input semantics.
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 names a specific verb ('List') and resource ('the ten ways to fund a small acquisition'), and further specifies what is included for each: requirements, seller acceptance, exclusions, and buyer cost. This clearly differentiates the tool from siblings like get_structure and list_funding_providers, which target a single structure or a provider list.
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 intended use is implied by the listing verb and the content description: call this when you want an overview of the ten acquisition funding structures. However, it gives no explicit guidance on when to choose it over alternatives such as get_structure or list_funding_providers, and no 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_postureget_structurelist_funding_providerslist_structuresFree SME valuation, sell-readiness, M&A pricing, partner and deal-referral tools in EN/FR/ES/PT.
Federal contractor M&A signals: rising contractors, growth momentum, award search.
Live index of startups that just raised funding, verified daily. Recent raises, lookups, stats.
OloLand M&A intelligence — 33 tools for deal analysis, valuation, risk, and cross-deal learning.
Add one secure layer between your agents and this server.
