Angels for Agents Funding

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe, non-persisting nature is covered. The phrase 'non-persisting readiness check' adds context about side effects, but the description does not disclose output behavior or other operational details like error handling or thresholds.

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 core action and context. No redundant wording or unnecessary detail, making it highly concise and well-structured.

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?

With six required parameters and no output schema, the description is too terse to fully contextualize the tool. It does not explain what the parameters signify, what readiness criteria are evaluated, or what the return value represents, leaving major gaps for an agent selecting and invoking 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?

Schema description coverage is 0%, and the description provides no explanation of the six parameters. The names alone (e.g., 'accountable_human_controller') hint at meaning, but the description neither lists them nor clarifies how they influence the readiness check, failing to compensate for the schema gap.

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 runs a non-persisting readiness check before collecting or validating a complete AFA pitch. It uses a specific verb ('run') and resource ('readiness check'), and distinguishes from siblings like validate_agent_pitch by positioning it as a pre-validation step.

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 provides explicit temporal context: use this tool 'before collecting or validating a complete AFA pitch.' It implies the tool is for preliminary checks rather than full validation, but it does not name alternative tools or explicitly state 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.

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, which covers the safety profile. The description adds value by specifying freshness and authoritative source URL, which hints at live data behavior beyond static annotations. However, it doesn't detail risk around open-world data or examples of failure cases, so it's adequate but not rich.

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 sentence that lists the key output aspects in a comma-separated series, which is concise and front-loaded. It is efficient without wasting words, though it might include too many specific output types that could be inferred from the record structure.

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 tool with one simple parameter and strong annotations (readOnly, openWorld), the description covers the core purpose and output. However, there is no output schema, so the description must carry the return value explanation; it does list output facets, but it doesn't explain how the result is structured (e.g., a JSON object with those fields). This is a minor gap for an otherwise simple 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?

Schema description coverage is 0%, but there is only one parameter, 'opportunity_id', and its schema is simple (string, length limits). The description implicitly clarifies that the parameter should identify a graph record but doesn't add examples or format details. Baseline 3 is fair because the parameter is self-explanatory even without description coverage.

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 the verb 'Resolve' with a specific resource ('one graph record') and details the outputs ('current published terms, eligibility language, award data, contact, freshness, and authoritative source URL'). It clearly distinguishes from siblings like 'get_open_capital_opportunities' or 'search_live_capital_opportunities' by focusing on a single graph record, though it does not explicitly name those siblings.

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 use when you need the latest published details for a specific opportunity, but it does not explicitly state when not to use it or mention alternatives (e.g., for searching, use search_live_capital_opportunities). The context is clear enough for a single-record retrieval, but no exclusions or alternative guidance is provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with 'Find'. The description adds that opportunities are 'current' and terms are 'live', implying time-sensitive data, which is useful behavioral context beyond the annotations. No contradiction.

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 sentence that is concise, front-loaded with the action, and contains no redundant words. Every phrase earns its place.

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 parameterless read-only lookup tool, this description is fully sufficient. It tells the agent what the tool does, when to use it, and what kind of output to expect (grant opportunities and their terms). No output schema exists, but the description covers the essential information.

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?

There are no parameters, and the schema is empty with 100% coverage, so the description is not expected to explain parameters. It instead clarifies what the tool returns (grant opportunities and live terms), which adds value in place of parameter details.

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 ('Find') and clearly identifies the resource ('current Angels for Agents grant opportunities') including their 'live terms'. It also states the purpose ('before preparing a pitch'), which distinguishes it from sibling tools that handle eligibility, submission, validation, and milestones.

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 explicitly indicates when to use the tool with 'before preparing a pitch', giving clear temporal context. While it doesn't name alternative tools or state exclusions, the sibling names (e.g., submit_agent_pitch, validate_agent_pitch) make the workflow context obvious.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by listing the facets returned (value, eligibility, constraints, provenance, access state, machine interface), giving the agent a clear idea of the tool's behavior beyond the generic 'retrieve'. It neither contradicts annotations nor introduces ambiguity, though it omits details like error behavior or permission requirements.

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, front-loaded sentence that begins with the action 'Retrieve' and lists the returned facets efficiently. No redundant words or fluff; every part contributes to understanding the tool's purpose.

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 read-only get-by-id tool with one parameter and no output schema, the description provides a solid enumeration of what is returned, making it largely complete. It doesn't mention how to find resource_id (e.g., via search_venture_resources) or what happens when the resource is not found, but these are not critical for selection and invocation in this context.

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 schema has only one parameter, resource_id, with no description (0% coverage), and the tool description does not explicitly explain how to obtain or format resource_id. However, the parameter name is self-explanatory and the phrase 'for one resource record' indirectly clarifies that resource_id identifies the resource, adding minimal meaning beyond the schema.

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 the specific verb 'Retrieve' and clearly scopes to 'one resource record', enumerating exactly what is returned (current value, eligibility, constraints, source provenance, access state, machine interface). This distinguishes it from the sibling search_venture_resources, which implies plural/search behavior.

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 phrase 'for one resource record' implies use when a specific resource is known, but the description does not explicitly state when to use this tool versus alternatives like search_venture_resources, nor does it mention any exclusions. Usage guidance is present but only implied.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the description is not required to restate that. It adds the requirement for controller authorization and 'existing' grant, but does not elaborate on what destructive effects might occur or any side effects. This is moderate additional context beyond 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?

The description is two short sentences with no fluff. The first sentence starts with the action verb 'Persist' and immediately conveys the core purpose, making it highly concise and front-loaded.

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 annotations (destructive, readOnly false) and the presence of a nested report object, the description is reasonably complete: it states what is persisted, the authorization requirement, and the fact that the grant is existing. It does not cover retry/idempotency details, but that is already specified in the idempotency_key schema description. No output schema exists, but return values are not critical for this kind of 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 schema already provides descriptions for idempotency_key and controller_authorized, covering 67% of parameters. The description mentions 'outcome metrics and evidence,' which loosely maps to the report object's required fields, but it does not explicitly explain each parameter or nested structure. Since schema coverage is moderate, the description adds marginal semantic value.

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 'Persist outcome metrics and evidence for an existing AFA Proof Grant' clearly states the action (persist), the resource (outcome metrics/evidence for a grant), and the specificity (existing AFA Proof Grant). It is distinctly different from sibling tools like 'submit_agent_pitch' or 'check_pitch_eligibility', so purpose is unambiguous.

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 phrase 'Use only after the responsible controller verifies and authorizes the exact report' provides an explicit precondition and clear context. It does not call out alternatives, but the specialized nature of the tool and the distinct sibling names make alternative use cases clear implicitly.

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

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

Annotations already indicate read-only and open-world behavior. The description adds a disclaimer about the results not being an offer or eligibility decision, which provides some context about the nature of the output, but it does not mention side effects, permissions, or rate limits beyond what annotations imply.

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 concise, consisting of two sentences, and is well-structured with a clear statement of purpose and a final disclaimer. No superfluous information is included.

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 provides some output details (deadlines, sponsors, status, freshness, URLs) and a disclaimer, but it lacks essential context: it does not explain what 'AFA' means, it does not describe the data source or coverage, and it omits any explanation of the search parameters. The overall completeness is inadequate for a tool with this complexity.

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 description does not mention any of the five parameters. The schema has no descriptions, so the tool definition offers no guidance on how to use 'query', 'status', 'sort', 'limit', or 'closing_within_days'. The description fails to compensate for the low schema coverage.

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 it searches capital opportunities and returns normalized data, but the abbreviation 'AFA' is undefined and the term 'source-linked' is vague. It partially distinguishes itself from sibling tools like search_venture_resources, but not fully.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or scenarios where this search is preferred over other search or retrieval tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable behavioral details: results are source-linked, and they distinguish discovery records from actual entitlements. This goes beyond minimal disclosure and provides insight into the returned data's nature.

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, tight and front-loaded. It starts with the action and resource, then adds a key differentiator. 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?

For a search tool with no output schema, the description covers core purpose and a notable result distinction, but it lacks guidance on how filters interact, pagination, result limits, or what a returned entry includes. It is adequate but leaves room for improvement in explaining usage context.

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 0%, so the description must compensate. It partially does by listing resource categories that map to the category enum, but it does not explain query, access_type, or availability semantics. The description adds minimal meaning for most parameters, leaving them underdocumented.

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 'Search' and the resource 'AFA's source-linked catalog', enumerating specific resource types (capital, compute, model, developer-tool, deployment, proof). It also distinguishes itself from sibling tools by noting that results differentiate discovery records from actual AFA entitlements, which sets it apart from get_venture_resource.

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 provides clear context that this tool is for searching a catalog, implying a browse/explore use case. However, it does not explicitly name alternative tools (e.g., get_venture_resource) or state when not to use this tool. It gives contextual guidance without explicit exclusions.

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

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

Annotations already indicate non-read-only, open-world, and destructive behavior. The description adds context about human review and the requirement for explicit authorization, which are useful behavioral traits beyond annotations. It does not fully elaborate on side effects, but the annotation coverage lowers the burden, and the added context is meaningful.

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: the first states the core purpose, and the second states the usage prerequisite. It is front-loaded, concise, and every word contributes value without redundancy.

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 purpose and usage guidelines but lacks explicit mention of response behavior or idempotency details. Given the tool's complexity (nested schema, no output schema), the absence of return-value or post-submission behavior information is a noticeable gap. However, the schema and annotations provide some context, making it adequate but not fully complete.

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 schema provides a detailed structure for the pitch object with nested properties, and the top-level fields have some descriptions for controller_authorized and idempotency_key. The description does not add parameter details but implies the payload must be validated. With schema coverage at 67% and a comprehensive schema, the description's parameter contribution is minimal, but the schema itself carries the 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 clearly states the tool persists a validated pitch for AFA human review, using the specific verb 'persist' and the resource 'validated pitch'. It distinguishes from siblings like validate_agent_pitch, which likely only validates, and emphasizes the authorization prerequisite, making the purpose precise and non-tautological.

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 explicitly states 'Use only after the accountable controller has reviewed the exact payload and explicitly authorized submission,' providing a clear precondition. It does not explicitly name alternative tools, but the sibling names and the conditional context imply this is the final submission step after validation, which is sufficiently clear.

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

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

Annotations already declare readOnlyHint and destructiveHint, so the bar is lower. The description adds valuable behavioral specifics: 'without storing or submitting it' confirms no persistence or submission side effects, and 'before requesting controller authorization' provides sequencing context. It does not describe return behavior, but the added context is meaningful.

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 that leads with the action and includes the key distinction (no storage/submission) and usage timing. Every word earns its place; no padding.

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 tool has a complex nested input schema and no output schema, so the description needs to explain return behavior or validation outcomes; it does not. However, the rich schema and sibling tool names provide enough context for basic selection and invocation.

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 0%, and the description fails to compensate by explaining the pitch structure or fields. The phrase 'complete AFA pitch' implies the object must be fully populated, but it adds no semantic detail beyond the parameter name and schema.

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 uses the specific verb 'Validate' with the resource 'complete AFA pitch,' and explicitly states 'without storing or submitting it,' distinguishing it from submission tools. It immediately signals the tool's purpose and scope.

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 when-to-use guidance: 'Use this before requesting controller authorization.' It also implies exclusion of submission actions via 'without storing or submitting it,' but it does not name alternative tools or state explicit when-not-to-use cases.

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