Server Quality Checklist

Tool Scores

• get_skillB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure, but it only says the tool fetches details. It does not mention read-only guarantees, not-found behavior, authentication requirements, or any side effects, leaving meaningful uncertainty for a zero-annotation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose, followed by a minimal parameter note. The Args block somewhat duplicates the schema, but the overall structure is clean and free of filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter lookup with an output schema, the essential call information is present. However, with no annotations and no sibling differentiation, an agent lacks guidance on failure modes and when this tool is preferable to search_skills. It is adequate but not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides no description for slug, so the description's 'The skill's unique identifier' adds necessary semantic meaning beyond the bare string type. It could explain slug format or how to find the slug, but for a single parameter this is reasonably sufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb ('Get') and resource ('full details for a specific skill') and identifies the lookup key as the slug. It implies a distinction from search_skills, but it does not explicitly name or contrast sibling tools, 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.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given for when to use get_skill versus search_skills or get_tool. The only implied condition is that the caller already knows the slug, but there are no alternatives, exclusions, or context cues to help an agent select this tool deliberately.

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

• get_toolB
  3.3/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full behavioral burden. It only says 'Get full details', which implies a read operation but doesn't disclose anything about potential errors, rate limits, required authentication, or the scope of 'full details' beyond what is obvious from the name.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: the main purpose appears in the first sentence, followed by a brief Args section. There is no wasted language or redundant repetition of schema fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple get-by-slug tool with only one parameter and an output schema, so the description doesn't need to elaborate on return values. The given purpose and parameter example suffice for a caller to invoke it correctly. The lack of usage guidance is a minor gap, but not blocking for a straightforward retrieval.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides no description for the 'slug' parameter, but the description adds a clear definition ('The tool's unique identifier') and a concrete example ('send-email-via-sendgrid'). With 0% schema coverage, this compensates well for the single parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the verb 'Get', the resource 'tool', and the identifying key 'slug', making the basic purpose clear. The phrase 'full details' distinguishes it from sibling tools like get_tool_quality and get_tool_metrics, which are more specific. However, it doesn't explicitly contrast with those siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as get_tool_quality or get_tool_metrics. The description only defines what the tool does, not the conditions that would recommend it over another sibling.

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

• search_appsB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description must carry the full behavioral burden. 'Search' implies a read-only operation and the pagination parameters imply paged results, but the description does not disclose result semantics, required authentication, or ordering. It adds useful context by defining apps as deterministic step pipelines, but not much else.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the purpose and followed by a tight, complete args list. Every line adds information and there is no filler, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple optional-parameter search with an output schema, the parameter documentation is adequate. However, the description does not address how this search differs from search_tools/search_skills or any behavioral caveats, leaving an agent short of full context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the param descriptions compensate well: query has natural-language examples, category is identified as a slug, pricing_type is constrained to free/paid, and tags are stated as comma-separated. Page/per_page are only minimally elaborated, which keeps this from being a 5.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource: 'Search for apps (deterministic step pipelines) on invok.it.' This clearly identifies what the tool does and the domain of its resource, which helps distinguish it from sibling search_tools and search_skills, though it does not explicitly call out those alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use this tool versus search_tools, search_skills, or get_app. The only signal is the word 'apps' in the description, so an agent must infer the selection criteria rather than being told.

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

• get_appA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It conveys that this is a read-only lookup ('Get full details'), but it does not mention how invalid or unknown slugs are handled, e.g., whether an error is raised or a null result is returned.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, front-loads the main purpose, and uses a clear Args block for the single parameter. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter lookup with an output schema, the description covers the core intent adequately. It lacks alternative routing and error-handling context, but these are not critical for a basic getter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only provides the parameter title 'Slug' with no description. The description adds meaningful semantics by stating that slug is 'The app's unique identifier', which compensates for the 0% schema description coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get full details') and the resource ('a specific app'), with the input identifier ('by its slug'). It does not explicitly distinguish itself from sibling retrieval tools like get_tool or search_apps, so it misses the full top score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'by its slug' implies that the agent should use this tool when it already has an app slug and needs full details. However, it gives no explicit guidance about when not to use it or when to prefer an alternative such as search_apps or get_tool.

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

• search_skillsA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals that this is a search/filter operation and that tags, category, pricing, and pagination affect results, but it does not explicitly state side-effect-free/read-only behavior or what happens when no query is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The opening sentence states the purpose, followed by a compact, well-formatted Args list. Every line adds semantic value beyond the bare schema property names, with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool with an output schema, the description covers all parameters and clarifies their meaning. It is slightly incomplete in not addressing when to prefer this over sibling search tools and in not stating pagination/result behavior explicitly, but those are minor gaps given the output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the Args block must fully compensate, and it does. It explains query as natural language with concrete examples, clarifies category expects a slug, pricing_type limits to 'free' or 'paid', tags are comma-separated, and page/per_page control pagination.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Search') and resource ('skills (multi-tool workflows) on invok.it'), immediately clarifying what the tool operates on. The parenthetical distinguishes it from sibling tools like search_tools and search_apps without needing to open the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives such as search_tools or search_apps. The query examples show what kinds of searches are possible, but there is no explicit context, exclusion, or routing to the correct sibling.

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

• get_manifestA
  4.1/5.0
  Behavior3/5

  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. 'Get' implies a read-only operation, and the enumerated contents signal what the response will cover, but the description does not explicitly state that this operation has no side effects or whether any auth is required to call it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that uses an em-dash to efficiently enumerate the manifest's contents. Every word earns its place, and it is neither padded nor under-specified.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with an output schema present, the description is complete and useful. It tells the agent exactly what the manifest covers, and there are no missing invocation details or ambiguous side effects that would block correct use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 document. The input schema already reflects this completely, and the description adds no parameter-related confusion. Baseline 4 is appropriate for a no-parameter tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource ('the invok.it platform manifest'), and enumerates its contents: capabilities, endpoints, auth methods, and rate limits. It is immediately distinguishable from sibling tools like get_app or get_tool, which target specific resources rather than the platform-wide manifest.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is the tool for retrieving platform-level metadata, but it does not explicitly state when to use it versus alternatives. Since it is the only manifest-related tool among the siblings, the intended use is reasonably inferable, but the guidance is not explicit.

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

• get_tool_alternativesA
  4.2/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the burden of behavioral disclosure. It implies a read-only lookup via 'Find' and clarifies the type-compatibility and category constraints, but it doesn't explicitly state that no mutation occurs, how results are ordered, or what happens when no alternatives exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the core purpose, and every sentence earns its place. The Args block is clear and directly maps to the parameters without unnecessary expansion.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple two-parameter lookup tool, and the description covers purpose, usage context, and parameter semantics. Since an output schema exists, return-value details don't need to be in the description; minor gaps like error behavior or no-result handling are acceptable but prevent a 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 does: the Args section explains that slug is the tool's slug identifier and that limit is the maximum number of alternatives with a default of 5. This adds meaning beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Find'), a specific resource ('type-compatible alternative tools from the same category'), and clarifies the scope. This clearly differentiates it from sibling tools like search_tools or get_tool, which serve different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance: 'Useful when a tool's circuit breaker is open or you want to compare options.' It doesn't mention when not to use it or name alternative tools, but the usage context is clear and actionable.

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

• submit_outcomeA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the full burden. It discloses the API key requirement ('Requires an API key (INVOKIT_API_KEY environment variable)') and notes that outcomes improve quality scores. However, it lacks details on side effects, idempotency, or any failure behavior, which is still relevant for a write operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is efficiently structured, beginning with the one-line purpose, followed by workflow context, API key note, and an Args list. No sentence is wasted, though the Args section is somewhat lengthy. It is front-loaded with the essential purpose and usage context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a feedback submission tool, the description covers purpose, workflow, API key, and all parameters explicitly. An output schema exists, so return values need not be described. It could mention what happens on success or failure, or if submissions are idempotent, but for this simple tool the coverage is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  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 does so thoroughly via an Args section that explains every parameter: slug and invocation_id are tied to invoke_tool, agent_id has a default and custom usage, semantic_accuracy and output_usefulness have explicit rating scales, task_completion is a boolean, and feedback_text has a max length. This goes well beyond the schema properties.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Submit quality feedback after invoking a tool.' It also contextually places this in a workflow ('search → invoke → report outcome'), making the tool's role unmistakable. No sibling tool does this, so it is clearly distinguished.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly ties usage to the feedback loop ('This closes the feedback loop: search → invoke → report outcome') and indicates it is a post-invocation action. It does not explicitly name alternatives or list exclusion criteria, but the workflow context is clear enough for an agent to know when to use it.

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

• list_categoriesA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavior. The verb 'List' implies a safe, read-only operation, and the statement about counts indicates the nature of the returned data. However, it does not disclose potential details such as ordering, pagination, or whether the counts are live/aggregated, though the presence of an output schema partially mitigates this.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficiently worded sentence that front-loads the action and resource, then specifies the output details. Every element is necessary and informative with no padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters), the description sufficiently communicates the operation, and the presence of an output schema covers return-value details. An agent can correctly invoke this tool based on the provided information alone.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the input schema fully covers the parameter surface. The description does not need to explain parameter semantics; stating that it lists all categories with counts is sufficient context for a no-argument call.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('List') and resource ('all tool categories') and further specifies the output content ('counts of tools, skills, and apps'). This clearly differentiates it from sibling tools like get_tool or search_tools by indicating a distinct aggregating/list operation rather than a lookup or search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly conveys this tool is for enumerating tool categories with associated counts, giving an agent a clear context for when to use it. It does not explicitly name alternatives or exclusions, but the read-only list semantics are readily apparent and distinct from the sibling tools.

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

• check_usageA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full disclosure burden. It discloses the authentication requirement ('Requires an API key (INVOKIT_API_KEY environment variable)') and the monthly time scope, and the verb 'check' implies a non-mutating read. It does not describe failure behavior (e.g., what happens without the key) or rate-limit specifics, but the output schema covers the return structure. No contradiction with annotations exists since none are present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three tight sentences, each earning its place: the first states the core purpose, the second discloses the environment-variable prerequisite, and the third gives the usage directive. The most important information is front-loaded, and there is zero filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, parameterless status tool with an output schema present, the description covers the essentials: what is checked, what auth is required, and when to use it. Return values are already handled by the output schema, so the only gap is error/edge-case behavior, which is minor for a read-only usage check.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema needs no documentation. Per the rubric, zero-param tools default to a baseline of 4. The description adds no parameter detail (correctly, since there are none to describe) and the context signal confirms 100% schema coverage. Nothing is missing here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb-resource pair: 'Check your current API usage, quota, and remaining calls for this month.' It names the exact resource being inspected (usage, quota, remaining calls) and scopes it to a time window ('this month'). It is clearly distinct from all siblings, which are tool/app/skill discovery and evaluation operations (search_tools, get_tool, get_metrics), so an agent can disambiguate it without reading schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 invoking tools to ensure you have remaining quota.' This is clear contextual direction for a pre-flight check. It does not name exclusions or alternatives, but none are needed since no sibling performs a usage check. The API-key requirement is also stated, reinforcing the preconditions for use.

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

• get_tool_metricsA
  4.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the nature of the output (raw performance metrics) and implies a read-only GET operation, but does not state side effects, authentication needs, rate limits, or pagination behavior. It adds some value by specifying the kind of data returned, but lacks depth for a tool with zero annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, front-loads the purpose, and organizes arguments in a clear list. Every sentence adds value: the purpose statement, the usage guidance, and the parameter descriptions are all relevant with no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with an output schema (the agent can see return structure elsewhere), the description covers purpose, usage, and all parameters. It does not mention error conditions or edge cases, but given the simplicity of the tool and the presence of an output schema, it is sufficiently complete for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  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 fully explains both parameters: 'slug' as 'The tool's slug identifier' and 'period' with explicit allowed values (hour, day, week, month, all_time) and the default. This adds meaning far beyond the raw schema types.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Get'), a specific resource ('raw performance metrics for a tool'), and enumerates what those metrics are (invocation counts, latency percentiles, error rate, uptime). It explicitly differentiates itself from get_tool_quality by noting the alternative is for a simple reliability check, so an agent can distinguish between the two tools without inspecting schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: 'Use this for detailed performance analysis' and explicitly calls out the alternative tool for a different use case: 'For a simple reliability check with an overall score, use get_tool_quality instead.' This is unambiguous and covers both application and exclusion.

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

• search_toolsA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral transparency burden. It explains the natural-language search behavior, filter semantics, price units, quality range, and pagination. It does not explicitly state that the operation is read-only or describe relevance/sort behavior, but those are largely inferable from 'Search' and the output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description opens with a one-sentence purpose and then uses a clean, scannable Args list. Every line adds information needed for correct invocation, with no filler or repetition of schema defaults.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a six-parameter tool with no annotations and an output schema, the description is largely complete: it explains the search task, all parameters, and how to discover valid categories. It does not mention result ordering or threshold semantics, but the output schema covers return values and the missing details are not critical for selecting or calling the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description is the only source of parameter meaning. It compensates fully by documenting all six parameters, adding a query example, category slug guidance, a 0-100 quality range, USD price units, and a per_page maximum of 100.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Search the invok.it marketplace for AI agent tools using natural language.' This clearly differentiates from siblings like search_skills and search_apps by targeting 'AI agent tools,' so an agent can tell what this tool is for without reading the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: natural-language queries, optional filters, pagination, and a pointer to list_categories for valid category slugs. It does not explicitly state when to prefer this over get_tool, search_skills, or search_apps, so it stops short of full alternative routing.

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

• get_tool_qualityA
  4.8/5.0
  Behavior4/5

  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 the return value and its components (success rate, schema honesty, latency consistency), implying a read-only operation implicitly via the 'Get' verb. It does not explicitly state that no data is mutated, but the context strongly suggests it. It adds value by describing the output breakdown beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear purpose statement, usage guidance, a sibling alternative, and parameter details. It is front-loaded with the main purpose and includes no redundant sentences.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given an output schema exists (which likely documents the return structure), the description covers purpose, usage, parameter semantics, and routing to an alternative. It is complete for an agent to call this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description's Args section provides essential meaning for both parameters: slug's role and period's allowed values ('hour', 'day', 'week', 'month', 'all_time'). This fully compensates for the schema's lack of descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves a quality score breakdown for a tool, with an overall 0-100 score and primary/secondary signals. It also explicitly differentiates from sibling get_tool_metrics by mentioning that detailed latency percentiles are handled there.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance on when to use this tool ('evaluate whether a tool is reliable enough to use') and names the alternative for detailed latency data, directing to get_tool_metrics instead.

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

• invoke_toolA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description must carry the full burden, and it does exceptionally well. It discloses the API key requirement, response composition (output plus latency, version, invocation ID), failure error codes (CIRCUIT_OPEN, RATE_LIMIT_EXCEEDED, TOOL_NOT_FOUND), and 503 alternative-tool behavior. This gives the agent a realistic model of what happens before and after the call.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is readable and front-loaded with the core purpose, then moves into authentication, response, feedback, and error recovery. Every section contributes useful information, though the error-recovery paragraph becomes slightly detailed. It remains appropriately sized for a proxy invocation tool with no annotations.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no annotations, an output schema, three parameters, and a rich failure model, the description covers all the necessary context: prerequisites, parameter semantics, expected response contents, error handling, and post-invocation follow-up. An agent has everything needed to invoke the tool correctly and recover from likely failures.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 defines slug with a concrete example, version with a default and example, and arguments by pointing to get_tool and explaining they are JSON matching the tool's schema. Examples for slug and version add value, but arguments could have been illustrated more concretely.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb-resource pair: 'Invoke a tool on the invok.it marketplace via transparent proxy.' It clearly targets a distinct action from siblings like get_tool, search_tools, and submit_outcome. The marketplace scope and proxy mechanism remove ambiguity about what this tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit workflow guidance: check get_tool first to understand the input_schema, then invoke, and afterwards use submit_outcome for quality feedback. It also instructs on failure recovery, telling the agent to switch to alternative tools or retry after the suggested delay. This goes well beyond implied usage.

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