Gondar

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

Adds real context beyond the annotations: it consumes one unit from a monthly allowance and deliberately stops short of submission, which explains why destructiveHint=true (quota consumption) despite nothing being applied. It does not say whether a consumed draft can be reclaimed or what the returned draft contains, leaving a modest 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?

Three short sentences, front-loaded with the workflow position and the gating condition, with zero redundant restatement of the tool name. Every clause carries a distinct constraint an agent needs.

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 two-parameter mutation with annotations but no output schema, the description covers the sequencing, the precondition, the quota cost, and the non-applying scope. The only shortfall is that the shape of the returned draft is implied rather than stated.

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% and both parameters are well documented in the schema, including the provenance of id and the single-use nature of confirmationToken. The description adds workflow framing but no additional syntax or format detail, so baseline 3 applies.

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?

States a specific verb and resource ('generate an application draft for a call') and situates it in a workflow as 'Step two', explicitly paired with prepare_draft as the preceding step. An agent can distinguish this from prepare_draft and from listing siblings like list_my_drafts without opening a schema.

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?

Gives an explicit precondition ('call it only after the user agreed to what prepare_draft returned'), a cost constraint ('uses one draft from the monthly allowance'), and a boundary ('it never applies: the user reviews the draft and applies at the official source'). This is close to complete when/where guidance.

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 establish that this is a safe, read-only, idempotent, non-destructive operation. The description adds useful context that some capabilities require a free account, but it does not describe the return format or whether there are any rate or auth constraints beyond 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 short sentences, front-loaded with the tool's contents and followed by a clear imperative. Every phrase contributes meaning with no waste.

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 zero-parameter informational tool with rich annotations and no output schema, the description covers the key content and usage timing. It could be slightly more explicit about the return shape, but nothing critical is missing.

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 there is no parameter semantics to document. Baseline 4 applies; the description correctly avoids irrelevant parameter detail.

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?

States clearly that the tool returns an overview of Gondar, the server's capabilities, and account-gated features. The purpose is specific to onboarding/context, but it does not explicitly differentiate itself from the sibling tools beyond being meta-information.

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 "Call it first" gives clear sequencing guidance for when to invoke this tool. It does not list exclusions or alternatives, but for a zero-parameter onboarding tool that omission is minor.

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, idempotentHint, closed-world and non-destructive, so the safety profile is fully covered. The description only adds that the scope is the signed-in workspace and that this data underlies fit scores; it says nothing about what the profile contains or how large it is.

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?

A single front-loaded sentence with the verb and resource first and the fit-score relationship second. Nothing is redundant with the name or title.

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 zero-parameter read with no output schema, the description covers what it returns at a high level and its relationship to fit scores. It stops short of enumerating profile fields, which is the only real gap for an agent that needs to know what it will receive.

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 takes zero parameters, so the baseline is 4. The description correctly implies no arguments are needed by scoping everything to the signed-in workspace.

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?

States a specific verb and resource ('read the signed-in workspace's applicant profile') and ties it to fit scores, which implicitly separates it from list_my_matches. It is clear about what it returns conceptually, though it does not explicitly name siblings the way a 5 would.

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?

Usage is implied rather than stated: an agent can infer it should call this to understand the basis of fit scores or to inspect its own profile. There is no explicit when/when-not guidance or named alternative such as list_my_matches.

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, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description adds that the response contains the call's facts plus its summary and official link, which is useful given there is no output schema, but it says nothing about behavior for unknown or expired ids.

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?

A single front-loaded sentence with no filler; the lookup key and the returned content are both stated up front.

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 two-parameter read with full annotation coverage, the description covers purpose, provenance of the key, and the shape of the result despite no output schema. Only error/not-found behavior is left unstated, a minor gap at 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?

Schema coverage is 100% and the id parameter's own description already states the provenance and format example. The description only restates that the id comes from search_open_calls and never mentions the optional language parameter, so it adds little beyond the schema. Baseline 3 applies.

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?

Specific verb and resource ('Read the facts of one call') with an explicit singleton scope that contrasts cleanly with the sibling search_open_calls. The mention of 'summary and official link' further signals what the agent gets back.

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 'by the id from search_open_calls' makes the prerequisite workflow explicit: search first, then fetch details. There are no explicit exclusions or notes on when not to use it, but the context is unambiguous.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is fully covered. The description adds only that results are scoped to the signed-in workspace and that drafts require review; it says nothing about ordering, volume, or what a draft contains.

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 short sentences, front-loaded with the action and scope. Nothing is redundant, though the second sentence is only marginally informative.

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 zero-parameter, non-destructive list tool with strong annotations, the definition is close to sufficient, but with no output schema the description does not indicate what a returned draft looks like or whether results are paginated.

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 takes zero parameters, so the baseline is 4. The description correctly implies no filtering or argument is needed beyond the implicit signed-in workspace context.

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?

States a specific verb and resource ('List the application drafts') and scopes it to the signed-in workspace, which separates it from the other list_* siblings. It does not explicitly distinguish itself from prepare_draft or create_draft, but the read-only listing intent is 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 note 'Drafts need review before use' implies the reason to call this tool, but there is no explicit when/when-not guidance or named alternative among siblings such as create_draft or prepare_draft. Usage is inferable rather than stated.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description still adds genuinely useful behavior beyond them: results are relevance-ranked ('best fit first') and each call carries a match score. It does not mention pagination behavior or whether results are capped despite the limit 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?

A single sentence with no filler that front-loads the resource, then scope, then ordering and payload. Nothing could be removed without losing information.

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?

There is no output schema, so the description carries the burden of describing returns; it does so partially (ordered by fit, includes score) which is the key information for ranking interpretation. The 100%-covered input schema handles the parameters, but pagination/result-cap behavior and the absence of profile prerequisites are unstated.

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% — every parameter, including the enum values and the region syntax, is documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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?

States a specific verb and resource (list open calls) scoped to matched-to-the-signed-in-workspace, which cleanly separates it from search_open_calls and list_saved_calls without naming them. It also conveys ordering (best fit first) and payload content (score per call) in the same sentence.

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 scope 'matched to the signed-in workspace's profile' implies when to use it — relevance-driven discovery for the current account — but there is no explicit when-not guidance or named alternative such as search_open_calls for unmatched querying. An agent must infer the routing decision from the phrasing.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds that results are scoped to the signed-in workspace and include stage and deadline, but says nothing about pagination, result ordering, or what an empty pipeline yields.

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 sentence, front-loaded with the verb and resource, with the scope qualifier and the returned fields packed in without redundancy. Nothing could be cut without losing information.

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 zero-parameter, read-only, closed-world list tool with no output schema, the description is nearly sufficient, and naming stage and deadline partially substitutes for the missing output schema. It could still say whether results are paginated or ordered, which an agent would want before rendering them.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The mention of stage and deadline usefully characterizes the payload even though it is not schema content.

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?

Specific verb ('List') plus a specific resource ('the applications in the signed-in workspace's pipeline') and even names the fields returned (stage, deadline). It does not distinguish itself from near-siblings like list_my_drafts, list_my_matches, or list_saved_calls, so it stops short of 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 phrase 'signed-in workspace' implicitly conveys that this is the current-user, no-argument view and needs no filters, which is useful scoping. But there is no explicit when-to-use statement, no exclusion, and no pointer to the sibling list tools an agent might confuse it with.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful scoping detail that results are limited to the signed-in workspace, but it does not discuss pagination, ordering, or return shape.

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 with no redundant or filler content. Every part of the sentence contributes to identifying the resource and its scope.

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 zero-parameter, read-only listing tool with rich annotations and no output schema, the description is nearly complete. It identifies the resource and workspace scope, though it could mention whether results are paginated or ordered.

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 there are no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description does not introduce any misleading parameter-related claims.

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 gives a specific verb and resource: "List the calls saved in the signed-in workspace." It clearly identifies the saved-calls collection and its workspace scope, though it does not explicitly contrast itself with siblings such as search_open_calls or list_my_drafts.

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 what the tool lists but gives no explicit guidance on when to use it versus alternatives like search_open_calls or the other list_* tools. The workspace scope is implied, but there are no exclusions or selection criteria.

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 idempotentHint=true, and the description reinforces this with 'It spends nothing' — resolving the non-obvious question of whether checking the plan consumes the monthly draft allowance. It also discloses the return value ('a confirmation token'), which matters because no output schema exists.

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?

Four short sentences, front-loaded with the workflow position and the no-cost guarantee, then the user-consent instruction. No filler; each sentence carries a distinct operational fact.

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 two-parameter precursor tool with no output schema, the description covers the workflow position, side-effect profile, the return artifact (token), and the required human-in-the-loop step. Nothing an agent needs in order to call it correctly is missing.

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 the id parameter documented including examples of where it comes from and the language enum listing defaults. The description adds nothing about either parameter, so the baseline 3 applies since the schema carries the full burden.

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?

Opens with a specific verb and resource ('Step one of creating an application draft for a call') and immediately distinguishes its role from create_draft by positioning itself as the preliminary step. An agent can tell what this does and where it sits in the workflow without opening the schema.

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?

Explicitly states the required sequencing: call this first, then 'call create_draft only after they agree.' It also prescribes the user-facing disclosure ('Tell the user that one draft will be used from the monthly allowance'), removing any inference about the confirmation gate.

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 write (readOnlyHint=false), idempotent, non-destructive, closed-world, so the safety profile is covered. The description's add-on, "It changes nothing else and applies for nothing," gestures at limited side effects and consistency with destructiveHint=false but is vague enough that its meaning is unclear.

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 first sentence is tight and front-loaded. The second sentence is short but cryptic, and it consumes space without conveying a checkable fact.

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 one-parameter tool with complete schema coverage and full annotation coverage, the description says enough to invoke it correctly. The remaining gap (what saving actually makes the call appear in, or how it differs from drafting) is minor but real.

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 the single id parameter, its format, and its provenance are fully documented in structured data. The description adds nothing beyond that, so the baseline of 3 applies.

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?

States a specific verb and resource ("Save a call to the signed-in workspace"), which is clearly distinct from read-oriented siblings like get_open_call or list_saved_calls. However, it never explicitly contrasts itself with create_draft or prepare_draft, which are the plausible write-side alternatives.

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 no when-to-use guidance, no prerequisites, and no alternatives. The only workflow hint (ids come from search_open_calls or list_my_matches) lives in the schema, not the description, and nothing explains when to save versus draft.

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 readOnly/idempotent/non-destructive, and the description adds the non-obvious constraint that results come 'from the first 50 rows of a list' and include an official link — real behavioral context beyond annotations. It stops short of saying what happens when offset exceeds that 50-row window.

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, front-loaded with purpose, then return shape and the row cap. Nothing is redundant; it could earn a 5 with one clause on the alternative tool, but it is efficient as written.

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-only search with a fully described schema and no output schema, the description covers purpose, result contents, and the 50-row scope limit. Minor gaps: pagination behavior relative to the row cap, and whether an empty result vs limited result is distinguishable.

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%, so all eight parameters are documented with enums and defaults in the schema. The description adds no syntax, default, or interaction detail beyond that, which is the expected baseline when the schema does the work.

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?

States a specific verb ('Search') and resource ('open grants, tenders, fellowships and other funding calls'), which is clear enough to separate it from get_open_call by plurality/search semantics. It does not explicitly name get_open_call as the single-record alternative, so the differentiation is inferred rather than stated.

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?

'Search' implies when to use it, and the sibling names (get_open_call, list_my_matches, save_call) suggest a natural role, but no when-not-to-use or alternative routing is given. No prerequisites or follow-up actions (e.g. save_call) are mentioned.

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