mcp-server-kilango

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools follow a clear resource+action pattern (portal, page, block, app, widget, connection), making them distinguishable. Some minor overlap exists: kilango_add_content_block vs kilango_place_widget both add items to a page, and kilango_move_block vs kilango_update_content_block/kilango_update_widget vs kilango_reorder_blocks all deal with positioning/moving elements. The descriptions do help disambiguate these cases, but an agent could misselect between move/reorder/update-position tools.
Naming Consistency5/5
All 48 tools follow a consistent `kilango_` prefix with verb_noun naming: list/get/create/update/delete/archive/publish/unpublish/save/add/place/activate/deactivate/install/uninstall/connect each pair with a clear object (portal, page, block, widget, app, connection). The pattern holds uniformly across all tools, making the naming predictable.
Tool Count4/5
48 tools is on the larger side, but the domain is genuinely broad — portal management, page building, widget placement, app lifecycle, connection management, and an escape hatch. Each tool covers a fairly distinct operation. However, there are many overlapping position/move tools (move_block, reorder_blocks, update_content_block, update_widget) that could arguably be consolidated, and the count feels slightly heavy.
Completeness5/5
The tool surface is remarkably complete for the domain: full portal lifecycle (create, update, get, list, publish, unpublish, archive, delete, preview, readiness), page CRUD with fine-grained block/widget operations, app catalog and installation/activation lifecycle, connection management, vocabulary discovery, navigation editing with ETag handling, and an escape-hatch call_operation for anything not covered. There are no obvious dead ends — even readiness blockers and force-publish edge cases are handled.
Average 3.6/5 across 48 of 48 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and readOnlyHint=false, which signals this is a mutating/destructive operation. The description adds only 'Requires an ADMIN key' beyond annotations, but doesn't explain what archiving actually does (does it hide the portal? is it reversible? does it affect published state?). For a destructive admin tool, this is a thin disclosure given no rich behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero waste. The ADMIN key requirement is front-loaded and relevant. It's concise, though potentially too spare given the parameter and behavioral gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, destructive annotations, undefined dryRun semantics, and no distinction from delete/unpublish tools, the description is insufficient. A destructive admin operation needs to clarify reversibility, effect on the portal's published status, and the dryRun parameter's behavior. The dryRun parameter alone is a significant completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions neither parameter. There's a 'dryRun' boolean parameter whose semantics are completely undocumented — the agent has no way to know if dryRun prevents the actual archive or what it returns. The portalRef is self-explanatory, but dryRun absolutely requires explanation that is entirely absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool archives a portal, which is a clear verb+resource pairing. However, it doesn't distinguish this from sibling tools like kilango_delete_portal, kilango_unpublish_portal, or kilango_update_portal — the archiving semantics vs. deletion vs. unpublishing are unclear. The title labels it ADMIN but the description doesn't explain what archiving means in contrast to these related operations.
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 notes it 'Requires an ADMIN key,' which is a prerequisite, but provides no when-to-use guidance, no exclusions, and no alternative tool references. For a destructive admin action with several adjacent sibling tools (delete, unpublish), the agent gets no help deciding when to use this vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, which the description's 'Remove' verb is consistent with but merely restates. The description doesn't add behavioral context beyond the annotation: no mention of whether removal is reversible, whether related config/installation is affected, whether it cascades to dependent data, or what happens if the block is referenced elsewhere. With a destructive operation and no output schema, it should disclose more.
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?
One sentence, zero waste, front-loaded with the action verb. It's appropriately terse given the simple operation. However, the conciseness comes at the cost of necessary information about the 0% schema coverage and behaviors, so while structurally tight, it under-serves.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with destructiveHint=true, no output schema, and 0% parameter documentation, the description should carry substantially more weight. It doesn't explain the dryRun parameter's safety purpose, doesn't mention reversibility, and doesn't clarify what 'app-widget' means relative to the portal/page context given the large sibling toolset. This is a mutating, destructive operation with minimal guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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. With 4 parameters (dryRun, blockId, pageRef, portalRef) at 0% coverage, the description adds nothing about what these parameters mean. Notably, the dryRun parameter could be a safety feature worth highlighting in a destructive tool, and that's completely absent. The description fails to compensate for the total lack of schema documentation.
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 'Remove an app-widget block from a page' uses a clear verb (Remove) with a specific resource (app-widget block) and location (from a page). It clearly distinguishes from sibling tools like delete_content_block, delete_page, and uninstall_app, since 'widget' is specific terminology. Missing nuance is that it doesn't differentiate from sibling delete tools explicitly, but the widget terminology is distinct enough.
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 on when to use this vs alternatives. It doesn't mention prerequisites (e.g., widget must exist, page must exist), doesn't note whether blocks can be re-added afterward, and doesn't clarify how this differs from delete_content_block or update_widget. The sibling set includes several delete/update tools, so guidance on when one applies over another would be valuable but is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the agent already knows this is safe. The description adds the context that it validates credentials against the source system (implying an external network call), which is somewhat useful. However, it doesn't disclose whether this is an expensive/slow operation, whether it may fail due to connectivity, or what happens for invalid credentials.
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?
A single clean sentence, no filler, no repetition of the tool name. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one undocumented parameter (0% schema coverage), no output schema, and no guidance on return values, failure modes, or when to use this tool, the description is minimal. It's adequate for basic comprehension but lacks the operational detail needed for an agent to reliably invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for the 'provider' parameter. The description mentions 'a connection's credentials' but doesn't clarify that 'provider' identifies which connection/system to check. It doesn't explain what values are acceptable (identifier format, system names vs. connection IDs), leaving the agent guessing about the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (verify a connection's credentials against the source system) with a clear resource. It distinguishes itself from siblings like list_connections and get_connection by emphasizing a verification/health-check action rather than retrieval, though it doesn't explicitly define what success/failure looks like or what information is returned.
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 on when to use this tool versus alternatives. It doesn't say that it triggers an active check against the source system (vs. returning stored state) or that it's appropriate before calling operations. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and idempotentHint=false, so this is a mutating, non-idempotent operation — the description correctly implies mutation. But it doesn't disclose what happens with dryRun behavior, whether updates are atomic, or what occurs when position is omitted vs combined with props. The dryRun parameter exists in schema but no behavioral context 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and reasonably concise. However, given 0% schema coverage and 6 parameters, it's under-specified rather than economically compact. The sentence is front-loaded with the purpose but lacks the depth needed for the parameter burden.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 params, 0% schema coverage, no output schema, and no annotation on mutation semantics, the description is insufficient. It names the action but leaves structural dependencies (portalRef/pageRef hierarchy), dryRun semantics, blocking behavior, and the relationship to kilango_move_block/reorder_blocks unexplained. For a tool performing two distinct behaviors (prop update and reordering), more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full compensation burden. It only mentions 'props and/or move it (position)' and the index/before/after constraint. It doesn't explain what portalRef/pageRef/blockId refer to, what dryRun does, or the position object semantics beyond the constraint already stated. Critical identifiers like portalRef/pageRef/blockId are completely undocumented.
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?
Clear verb+resource+scope: 'Update a content block's props and/or move it (position).' It distinguishes props update from position change. However, it doesn't explicitly differentiate from sibling tools like kilango_move_block and kilango_reorder_blocks, which likely cover position changes — a meaningful differentiation gap.
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 says 'Position is at most one of index/before/after' which gives some usage constraint. But it doesn't explicitly say when to use this vs kilango_move_block or kilango_reorder_blocks, or when NOT to use it. Sibling tools suggest overlap on the moving functionality, and no guidance resolves this ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false (mutation) and openWorldHint=true (may have side effects beyond visible returns). The description adds minimal behavioral context - it doesn't mention whether this is reversible, whether dryRun affects behavior, what the return/payload looks like, or the semantics of visibility object values. With openWorldHint=true and idempotentHint=false, the description carries a heavier burden to explain side effects, which it fails to do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient, but it telegraphs a lack of informative content. While there's no redundant bulk, the extreme brevity means the single sentence must carry substantial weight - particularly for ambiguous parameters like dryRun and the free-form visibility object - which it does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool (readOnlyHint=false) with openWorldHint=true, 6 parameters including a free-form nested visibility object, and no output schema. The description is far too minimal for this complexity. It doesn't explain dryRun, the visibility object structure, required references (portalRef, pageRef), or any return-value expectations. Compared to the HIGH calibration example, this tool needs substantially more description than it has.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 for the 6 parameters. The description names three of them (title, sortOrder, visibility) but omits portalRef, pageRef, and dryRun from meaningful explanation. Notably, dryRun is a non-obvious parameter whose behavior (preview vs actual update?) is entirely unexplained. The visibility nested object with free-form propertyNames is completely undefined in both schema and description.
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 verb (Update) and resource (a page), and lists the specific updatable fields (title / sortOrder / visibility). This distinguishes it from sibling tools like create_page, delete_page, and save_page_layout. It could be slightly more explicit about being a metadata-only update (not layout/blocks), but the field list gives good clarity.
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 on when to use this vs. alternatives like update_portal or save_page_layout. The description implies it's for page metadata updates, but there's no explicit when-to-use or when-not-to-use guidance, and no mention of the dryRun parameter's role in validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds the slug-immutability constraint, which is useful. However, with no output schema and no annotation-heavy safety profile, the description should disclose more: what happens to unmodified fields, whether the update is partial or full replacement, auth requirements, and behavior of dryRun. 'Update' implies mutation but consequences are unexplained.
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?
Two sentences, front-loaded with the action and mutable fields, no filler. It is appropriately compact. Minor deduction for not using the space to cover the dryRun parameter or kind value constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Update operations are typically stateful and consequential. With no output schema, no annotations detailing side effects (only flags), and 0% param coverage, the description should provide more: what defines a successful update, whether it's a PATCH-style partial update, and how dryRun behaves. The slug immutability note is good but insufficient for a mutation tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description is the only source of parameter meaning. It names name/kind/defaultPersonaId in prose, but adds no detail on the 'kind' values allowed, what portalRef refers to (ID vs name vs reference string), or what dryRun does. The dryRun parameter is entirely undocumented in both schema and description, and its presence is significant for an update tool.
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 verb (Update) and resource (portal), and lists the specific mutable fields (name / kind / defaultPersonaId). It distinguishes from siblings like delete or create by explicit action. However, it doesn't differentiate from other update tools (update_page, update_widget) beyond the resource name, which the title already implies.
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 lists what can be updated and notes the immutability of slug (a useful exclusion). However, it provides no guidance on when to use this vs alternatives, no mention of dryRun semantics for testing, and no context about portal prerequisites (e.g., must exist, must be in a certain state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds the cascading widget removal detail, which is useful behavioral context beyond the annotations. However, it doesn't disclose reversibility, what happens to existing settings, or whether dryRun affects the cascade. Given annotations carry the core safety profile, a 3 is appropriate.
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 efficient—two short sentences with no waste. It front-loads the primary action clearly and then adds the key behavioral note about cascading. The structure is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool (destructiveHint=true, idempotentHint=false) with no output schema and no parameter semantics in the description, this is incomplete. The dryRun parameter is undocumented, the cascade behavior lacks detail (what exactly is removed, reversibility), and there's no mention of prerequisites like existing app installs. A destructive tool should provide more guidance on safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions none of the three parameters. The dryRun parameter's semantics are entirely undocumented—the agent must infer that it previews the deactivation without executing it. portalRef and appKey are only explained by their names. With a 0% coverage and no description compensation, this scores well below baseline.
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 ('Deactivate an app in a portal') with a specific verb and resource. It distinguishes from siblings like kilango_activate_app_in_portal, kilango_install_app, and kilango_uninstall_app by implying this toggles an app state within a portal context. However, it doesn't explicitly differentiate itself from activate or uninstall, and mentions cascading widget removal which adds functional clarity.
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 vs alternatives like kilango_uninstall_app, kilango_activate_app_in_portal, or kilango_archive_portal. It's not stated whether this is reversible, whether activation restores the widgets, or when deactivation is preferred over uninstallation. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide strong safety signals (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar for behavioral disclosure is lower. The description adds the concept of 'scope capabilities' which hints at some behavioral output structure beyond the annotations. However, it doesn't disclose return format, pagination, or whether the list is exhaustive.
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 a single concise sentence with no wasted words. It front-loads the core action ('List') and resource. However, it's arguably under-specified rather than appropriately concise—one could imagine a slightly longer but more informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no parameters and no output schema, the description does minimal work. It conveys it lists providers but doesn't clarify what a 'provider' is in this domain, whether the list is sortable or filterable, what 'scope capabilities' means concretely, or how this differs from the closely-named 'kilango_list_connections' sibling. The domain terminology is left unexplained.
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?
There are 0 parameters, and with 100% schema coverage this is essentially a no-op dimension. Per the rubric, 0 params defaults to baseline 4. No additional parameter explanation is needed since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('List') and resource ('providers') plus a scope qualifier ('and their scope capabilities'). However, 'providers' is ambiguous—it's unclear if this refers to connector providers, data providers, or service providers. Among siblings, 'kilango_list_connections' and 'kilango_list_connectors' are closely related, and this description does not clearly distinguish between them, making the differentiation weak.
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 like 'kilango_list_connections' or 'kilango_connect_app'. The relationship between connectors, connections, and apps is not explained. An agent cannot determine whether to reach for this tool or a sibling without additional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, covering the core behavioral safety profile. The description adds the ADMIN key requirement, which is meaningful auth context. However, it doesn't disclose what happens to associated content blocks, widgets, or related resources when a page is deleted, nor whether deletion is reversible.
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?
One sentence, zero waste, directly meaningful. The title 'Delete Page (ADMIN)' also reinforces purpose. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no output schema, 0% parameter coverage, and no behavioral notes about consequences or irreversibility. The description is far too thin for the risk profile of the operation. It should mention what dryRun does, whether deletion cascades to content blocks/widgets, and error conditions. Given the destructive nature, this level of underspecification is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter meaning beyond the schema. The schema reveals portalRef and pageRef (both minLength 1 strings, self-explanatory) and dryRun (boolean, default false), but the description doesn't explain what dryRun does, what format portalRef/pageRef take, or what the ADMIN key requirement means for invocation. With 0% coverage the description must compensate and does not.
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 verb (Delete) and resource (page), which distinguishes it from sibling tools like kilango_create_page, kilango_update_page, and kilango_get_page. The 'Requires an ADMIN key' clause adds a privilege qualifier. However, it doesn't explicitly distinguish from kilango_delete_portal or other delete siblings at the same level of clarity, though the resource is clearly 'page'.
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 on when to use this tool vs alternatives. It doesn't mention that it may be safer to first use dryRun, or that get_page/list_pages might be helpful before deleting. The ADMIN key requirement is a gate but not contextual guidance about when deletion is appropriate or how it relates to publishing/archiving alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false (it mutates) and idempotentHint=false, but the description doesn't disclose any additional behavioral context. It doesn't explain what happens on repeated activation, whether reactivation is safe, whether deactivation of another app is required first, or what 'optional per-portal config' does. With no output schema, the agent has no idea what the response looks like or side effects beyond what annotations declare.
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?
Two concise sentences, front-loaded with the core action and purpose. The phrase 'optional per-portal config' is compact and adds value. Could arguably add more, but it avoids waste and gets to the point efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations for behavioral nuance, no output schema, and 0% parameter coverage, the description is thin. It establishes the core purpose and prerequisite relationship but leaves the agent guessing about return values, config semantics, idempotency behavior (despite openWorldHint), error conditions, and relationship to adjacent operations (install, deactivate, place_widget).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 for the 4 parameters. It only names 'config' as 'optional per-portal config' and implies the others but names none. The context signal of an openWorldHint true suggests config values are arbitrary and open-ended, which is partially communicated by the 'optional per-portal config' phrase, but portalRef and appKey get no semantic enrichment beyond their schema types.
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 verb (activate), resource (installed app), location (in a portal), and adds the purpose ('precondition for placing its widgets'). This distinguishes it from install vs uninstall vs deactivate siblings. It doesn't explicitly name the sibling alternative but the purpose context implies the surrounding workflow.
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?
It states when to use it (as a precondition before placing widgets) which provides some workflow context. However, it doesn't explicitly say when NOT to use it or name alternatives like kilango_install_app for first-time setup vs this for activation of an already-installed app. The precondition clause gives implied usage guidance but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful domain context about stable blockId and widgetInstanceId for app-widget blocks, which is meaningful. It doesn't describe the response format, pagination, or ordering semantics, but given strong annotation coverage, a 3 is appropriate.
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?
Single concise sentence plus a follow-up about blockId stability. Both earn their place: the second sentence explains the significance of blockId for subsequent operations (like targeting blocks for updates/moves). No wasted words.
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?
This is a straightforward read-only list operation with strong annotations and only 2 parameters, so the completeness bar is lower. The description adequately explains the return content (ordered blocks, stable IDs). However, it doesn't explain the ordering semantics (what 'ordered' means), how to obtain portalRef/pageRef, or what distinguishes this from kilango_get_page. Adequate but with room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning. The description implies the tool takes a portalRef and pageRef to identify which page's blocks to retrieve, but doesn't explicitly explain what these references mean, their format, or how to obtain them. The names are fairly self-explanatory, but the description adds minimal semantics beyond the schema.
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 verb ('Return') and the resource ('ordered blocks of a page'). It distinguishes itself from sibling tools like kilango_get_page (which likely returns page metadata) by focusing on blocks specifically. However, it doesn't explicitly contrast with close siblings like kilango_get_page or kilango_get_page_navigation.
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 on when to use this tool versus alternatives. While the read-only focus is clear (distinct from add_content_block/update_content_block/reorder_blocks), the description doesn't mention exclusions or when it should be preferred over related getters like kilango_get_page or kilango_get_page_navigation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false (mutation), openWorldHint=true, but no idempotence or destructive flags. The description states it updates config and/or position, indicating a non-destructive mutation. However, it doesn't disclose the dryRun parameter behavior, what happens when only some fields are provided (partial vs full replacement), or whether position conflicts with move_block/reorder_blocks tools. With modest annotation coverage, the description adds some value but misses key behavioral context around the dryRun flag and partial vs full update semantics.
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?
One sentence, front-loaded with the verb and subject, tight and economical. No redundant phrases or filler. The description efficiently conveys the core purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (6 params, nested position object, dryRun mode, open-world config) with no output schema. The 13-word description provides only the core purpose. It fails to explain the dryRun parameter (critical for a mutation tool), the position semantics relative to before/after/index, how the arbitrary config object is applied, or the distinction from place_widget/move_block/reorder_blocks siblings. For a tool of this complexity with zero schema coverage and no output schema, the description is minimal rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 for 6 params, but it only mentions 'config' and 'position' by name. The description doesn't clarify that config takes arbitrary key-value pairs (open schema), how position's after/index/before properties interact, or what dryRun does. The position object with mutually-exclusive-looking fields (after/before/index) is undocumented. Given 0% coverage and 3 undocumented optional params, the description falls short of compensating.
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 tool name 'kilango_update_widget' and title 'Update App Widget' clearly signal verb+resource. The description adds specific scope ('app-widget block's config and/or position'), distinguishing it from siblings like place_widget, delete_widget, and move_block for pages/blocks. It's clear what resource is being acted upon, though it doesn't name the exact fields beyond 'config and/or position'.
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 when-to-use guidance, no exclusions, and no mention of alternatives. With siblings like kilango_place_widget (placement), kilango_move_block (position), kilango_update_content_block (content blocks), and kilango_reorder_blocks (ordering), there's ambiguity about when to use this vs those. However, the config vs position distinction partially implies usage scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, which already communicate that this is a non-idempotent mutation. The description 'Remove a block' aligns with these annotations without contradiction. While the description doesn't add much beyond the annotations (e.g., no mention of irreversible consequences or dependent data), it doesn't contradict them either, and the destructive nature is clearly labeled in the annotations.
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 a single short sentence, which is appropriately concise. However, it is slightly under-specified — a bit more detail about the dryRun parameter or the parameters' relationship would be warranted while keeping it concise. Still, for the core purpose statement, there is zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema and zero parameter-format documentation, the description is under-equipped. It doesn't explain what dryRun does, how blockId relates to the page structure, whether deletion cascades, or what happens to the page after removal. The annotations help signal destructiveness but the description doesn't add the operational context an agent needs to safely invoke a destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter documentation. However, the description provides no information about what portalRef, pageRef, blockId mean or how they relate. The dryRun boolean parameter is entirely undocumented in the description — an agent would not know it provides a dry-run mode. This is a significant gap given zero 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 'Remove a block from a page' uses a specific verb (Remove) and clearly identifies the resource (block) and location (from a page). It distinguishes from siblings like add_content_block and update_content_block, though it doesn't explicitly name those alternatives. Clear and unambiguous action.
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 usage context (removing blocks from pages) but provides no explicit when-to-use vs alternatives guidance, no prerequisites (e.g., needing pageRef or existing block), and no exclusion cases. The parameter names and sibling context make usage reasonably inferable, but the description itself offers no explicit directional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is well covered structurally. The description adds the specific return content (pinned manifest version, config, status), which is useful behavioral context beyond the annotations. It doesn't describe what happens on not-found or error conditions, but with strong annotation coverage the bar is met.
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?
One sentence, zero waste, exactly captures the tool's purpose and return content. Front-loaded with the verb and resource. There is nothing extraneous.
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?
This is a simple fetch-by-key tool with one string parameter and strong annotations covering behavior. No output schema exists, but the description mentions the key fields returned. For a read of this simplicity, the description is adequate but could benefit from explaining what an 'appKey' is and how it relates to the installation context, given no schema descriptions exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 for explaining the single parameter. The description does not add any meaning to 'appKey' beyond its name — it doesn't explain what an app key refers to, where to find it, or its format. With only one parameter and 0% coverage, this is a missed opportunity, though the parameter name itself is fairly self-explanatory.
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 verb ('Return') and resource ('installation record') with a parenthetical listing of what that record contains (pinned manifest version, config, status). It distinguishes from siblings like kilango_list_app_installations (which lists multiple) and kilango_install_app (which creates). However, it doesn't explicitly contrast with these siblings in the description itself, so it misses the 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. With siblings like kilango_get_catalog_app, kilango_list_app_installations, and kilango_get_connection, there could be confusion about which lookup tool fits which scenario. No explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile well. The description adds the behavioral context that it returns the page 'including its layout,' which goes slightly beyond annotations. No contradiction with 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?
A single clear sentence that communicates the tool's core function with zero wasted words. It's appropriately succinct and front-loaded with the key action.
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?
This is a relatively simple read tool with good annotations and only 2 parameters. However, with 0% schema coverage and no output schema, the description could provide more value by clarifying the pageRef format (slug or id) and what 'layout' means in the return payload. It's functional but leaves the agent inferring some details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It mentions 'by slug or id' but doesn't explain which parameter maps to slug vs id (pageRef presumably supports both formats). Neither pageRef nor portalRef is explained in detail, which is a significant gap given zero schema 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 what it does: 'Fetch one page (by slug or id) including its layout.' The verb+resource pairing is specific and meaningful. It distinguishes from siblings like kilango_get_page_blocks and kilango_list_pages, though it doesn't explicitly differentiate itself.
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 when to use it (when you need a page's layout), but never names alternatives or says when NOT to use it. With siblings like kilango_get_page_blocks and kilango_list_pages, there's implied context but no explicit guidance on choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations comprehensively cover the behavioral profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true. The description adds the return payload contract ({ previewUrl, token }) and the DRAFT constraint. However, it doesn't explain what previewUrl or token are used for, token lifespan, or any prerequisites (e.g., must portal be in draft state, what happens if published). Annotations do the heavy lifting here, so the description adds modest value beyond them.
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, compact sentence that front-loads the return type and scoping constraint. Every element earns its place, and there's no filler or redundancy. Very concise and clean.
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 single-parameter read-only tool with comprehensive annotations, the description is adequate but minimal. It lacks context about what the preview actually provides (a rendered view? a link? what does token grant?), token expiration semantics, or behavior when the portal isn't in draft state. Given the draft-scoped purpose and one parameter, more context could help agents decide when previewing is appropriate versus listing or fetching a portal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there's only one parameter, portalRef. The description does not elaborate on what portalRef should be (ID format, how to obtain it). With zero schema coverage, the description carries the burden but says nothing about this sole parameter beyond its existence in the input schema. The description does not compensate for the coverage gap.
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 'Return { previewUrl, token } for previewing a DRAFT portal' uses a specific verb (return/preview) and a clear resource (portal), and crucially disambiguates from sibling tools like kilango_get_portal (which fetches portal data) and kilango_list_portals (which lists portals). The DRAFT scoping is a meaningful differentiator against get_portal. This clearly distinguishes it from its siblings.
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 for previewing draft portals, which establishes a general usage context but doesn't explicitly state when to choose this over alternatives. It doesn't name alternative tools (though the DRAFT constraint hints against using get_portal for preview purposes) or describe exclusions like 'does not preview published portals.' The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide openWorldHint=true and destructiveHint=false, indicating a non-destructive state change. The description adds the key behavioral detail that the tool transitions the portal to DRAFT status, which is useful. However, it doesn't disclose whether the tool errors if the portal isn't currently published, or whether the preview URL changes, missing opportunities to add non-annotation context.
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 a single, concise sentence that efficiently states the tool's purpose. Minimal waste, though it could add a note about dryRun behavior without becoming verbose.
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?
This is a mutation tool with no output schema and sparse annotations. The description tells the agent the end state (DRAFT) but not about reversal (publish_portal), failure conditions, or the effect of dryRun. For a state-changing operation with idempotentHint=false, the description is adequate but leaves the agent without key operational context like idempotency semantics.
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?
There are only 2 parameters and schema description coverage is 0%, so the description must carry the burden for parameter meaning. The dryRun parameter is not self-explanatory from the schema alone, but the description doesn't elaborate on it. However, with only 2 simple params (portalRef being obvious and dryRun being a common boolean pattern), the low complexity reduces the need for extensive explanation. The description could mention dryRun's purpose but doesn't strongly detract.
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 'Take a portal offline (back to DRAFT)' clearly states the verb (take offline), resource (portal), and resulting state (DRAFT). It distinguishes from sibling publish_portal (which goes live) and archive_portal (which implies terminal state), though it doesn't explicitly name 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?
No guidance on when to use this tool vs alternatives. Sibling tools like archive_portal and delete_portal represent distinct lifecycle states, but the description doesn't explain when unpublish is the right choice versus those alternatives, nor does it mention prerequisites (e.g., must be published first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the etag behavioral detail (linking to save operation), which is useful context. However, it doesn't describe return format beyond { navigation, etag } or any pagination/structuring of the tree.
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 a single efficient sentence that communicates the return type and the key behavioral fact (etag needed for saving). No wasted words. It's concise without being under-specified.
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 read tool with one parameter and strong annotations (readOnly, idempotent, non-destructive), the description covers the essentials. However, the 'openWorldHint=true' suggests the tool operates on dynamic data, and the description doesn't explain what 'navigation tree' contains structurally or whether it reflects staged vs published state, which could matter for an agent deciding between get_portal_navigation and get_portal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the one parameter (portalRef) is undocumented in both the schema and description. With only 1 parameter and a self-explanatory name (portalRef meaning portal reference), the baseline is moderate. The description adds no meaning beyond what 'portalRef' conveys, so it's a standard 3.
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 tool returns the portal navigation tree with navigation and etag fields. The specific verb 'Return' plus the resource 'portal navigation tree' is clear. It distinguishes itself from siblings like save_portal_navigation by noting the etag is needed for saving, though it doesn't explicitly name the sibling.
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 usage (get navigation, use etag for saving), which points toward kilango_save_portal_navigation as a paired operation. However, it lacks explicit when-to-use vs alternatives, no mention of prerequisites like whether the portal must exist or be published, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so mutation is implied. The description adds modest context: sortOrder controls navigation order, and layout is a separate concern. It doesn't disclose behavior around duplicates (e.g., what happens if the slug already exists), whether it's idempotent, or any side effects. Given annotations carry the safety profile, this is an adequate but not rich disclosure.
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?
Two sentences, both earning their place. The first states the core action, the second explains the sortOrder parameter and correctly redirects layout concerns to sibling tools. Slightly terse but efficient with no 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?
With 6 parameters, 0% schema coverage, no output schema, and nested objects, the tool needs more support than it receives. The visibility object and dryRun parameter are undocumented. The description gives good pointer context for sortOrder and layout separation, but for a create operation with 3 required params and a complex visibility object, there's meaningful undocumented surface area. No output schema means the return format is also undisclosed.
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 has 0% description coverage, so the description must compensate for parameter meaning. It explains sortOrder's role (page order in navigation), which is genuinely useful semantic info not in the schema. However, it doesn't explain the 'visibility' nested object parameter or the 'dryRun' flag, which remain undocumented given zero schema coverage. It partially compensates but leaves gaps.
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 tool's purpose: 'Create a page in a portal.' The verb+resource pairing is specific and unambiguous. While it doesn't explicitly name the sibling differentiation (kilango_update_page vs this create operation), the action itself is clear enough to distinguish from the listed sibling tools.
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 provides useful context that layout is handled separately via kilango_save_page_layout / kilango_add_content_block, which prevents the agent from expecting layout setup here. However, it doesn't explicitly state when NOT to use this tool or contrast it with update_page vs create scenarios. It names alternative tools for a follow-up step but not as exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context by noting it never returns the secret, which is a meaningful behavioral constraint beyond what annotations provide. This is useful security-relevant transparency.
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 one concise sentence with zero filler. The parenthetical adds valuable clarification about what's returned (status/health) and what's excluded (secrets) without waste. Perfectly sized for the tool's simplicity.
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 single-parameter read tool with strong annotations, the description is fairly complete. It specifies the purpose, the return scope, and the security constraint. It could benefit from mentioning the return format or how provider values are validated, but given no output schema exists and this is a simple lookup, coverage is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there's only one parameter (provider) with no description in the schema. The description mentions 'for one provider' which maps to the provider param but doesn't explain what valid provider values are or how providers are identified. Since coverage is 0%, the description should compensate but only minimally addresses the 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 clearly states the tool returns a connection for a provider, specifically status/health information. The verb 'Return' with resource 'connection' is specific. However, it doesn't explicitly distinguish from sibling tools like 'kilango_get_connection' vs 'kilango_list_connections' or 'kilango_check_connection_health' which could overlap, giving it a strong but not perfect 4.
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 for fetching connection status for a single provider, which implies single-item retrieval. However, it doesn't explicitly say when to use this versus 'list_connections' or 'check_connection_health' siblings, which would be valuable given the close functional overlap. No explicit alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by stating the resource identity options (uuid or slug) and listing the return payload fields, but no additional behavioral context like pagination, error handling, or ETag semantics is disclosed.
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 a concise single sentence plus a compact return-list enumerator. It front-loads the purpose and packs the payload details efficiently. No 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?
Given the tool is a simple single-parameter read with strong readOnly/openWorld/idempotent annotations, the description adequately covers what it does and what it returns. Though there's no output schema, the description lists the return components (counts, domains, urls, navigation, theme overrides, ETag), which mitigates the missing output schema. Slight gap: no note on what happens for an invalid or ambiguous uuid/slug.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there's only 1 parameter (portalRef). The description mentions lookup 'by uuid or slug' which tells the agent what type of reference is acceptable, so there is some added meaning beyond the bare schema. However, it doesn't clarify the expected format/type of uuid vs slug, so the single parameter's semantics are only partially elaborated.
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 fetches one portal by uuid or slug and enumerates exactly what it returns (counts, domains, urls, navigation, theme overrides, navigation ETag). The verb+resource+lookup-method is specific and distinct from siblings like kilango_list_portals (list) and kilango_get_portal_preview (preview).
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 establishes the lookup by uuid or slug, which gives context on how to identify a resource, but does not explicitly state when to choose this over alternatives like kilango_get_portal_preview, kilango_get_portal_navigation, or kilango_get_portal_readiness. No explicit exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the ordering-by-sortOrder detail, which is useful behavioral context. However, it doesn't disclose the return structure or whether pagination applies, though no output schema exists to compensate.
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?
A single clean sentence that conveys purpose and ordering. Zero wasted words. For a read-only list operation with one parameter, this is appropriately minimal.
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 read-only list operation with strong annotations (readOnly, idempotent, non-destructive) and a single well-named parameter. Given the low complexity, the description plus annotations provide adequate context. It could mention what a page represents or that navigation structure is involved, but for the operation's simplicity it's largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The description indicates portalRef (the portal position) is the scope, and that results are ordered by sortOrder. However, it provides no detail about what 'sortOrder' means, what portalRef format is expected, or what the response looks like. The single-parameter nature keeps the burden modest.
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?
Description states 'List the pages of a portal, ordered by sortOrder' — a specific verb (list) + resource (pages of a portal) + ordering detail. It distinguishes from siblings like kilango_list_portals (lists portals, not pages) and kilango_get_page (single page), though doesn't explicitly name the alternatives.
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 for retrieving pages within a portal context (requires portalRef), contrasting naturally with single-page retrieval tools like kilango_get_page. However, it doesn't explicitly state when to use this vs alternatives, or mention that this returns all pages rather than filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the description's read-only nature is structurally disclosed. The description adds little behavioral context beyond what annotations provide — it doesn't clarify return format details or how activation status is determined, though the minimal essence is captured.
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?
A single concise sentence that fully states the tool's purpose. Zero filler, zero wasted words. This is appropriately compact for a simple list operation.
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 read-only list operation with strong annotations (readOnly, openWorld, idempotent) and a single parameter, the description is largely adequate. It doesn't explain what fields the returned list contains, but with no output schema and a straightforward purpose, the minimal description suffices. A small addition about what info each app entry shows would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 carry the burden for the single parameter, portalRef. The description names the target portal ('in a given portal') which loosely connects to portalRef, providing some meaning. However, it doesn't specify what format portalRef expects (ID, name, ref string) beyond the schema's minLength constraint.
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 tool lists which installed apps are activated in a given portal. The verb 'list' plus resource 'installed apps activated in a portal' is specific. It distinguishes from siblings like kilango_list_catalog_apps (catalog apps) and kilango_list_app_installations (installations generally), though it doesn't explicitly name them.
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 gives clear context (activated apps in a portal) but no explicit when-to-use guidance or exclusion statements. Given the sibling tools like kilango_get_app_installation, kilango_list_app_installations, and kilango_activate/deactivate_app_in_portal, some differentiation guidance would help, but the purpose is self-evident enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds value beyond these by explicitly stating 'idempotent' (which contradicts the idempotentHint=false annotation semantically — though the annotation seems conservative, the description explicitly claims idempotency). It also discloses the 'force' behavior and readiness-blocker override semantics. However, it doesn't clarify what happens to an already-published portal or what the readiness check involves.
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 a tight single sentence plus one clause explaining force. It's front-loaded with the core intent. No wasted words. Could arguably be scored 5 but the terse style leaves out useful detail that would justify extra length.
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?
The tool is a state-changing publish operation with no output schema and no annotations carrying safety info. The description doesn't mention return format, does mention idempotency and the force flag. For a publish action, an agent would benefit from knowing what response to expect (published confirmation? portal URL?) and non-overridable blocker behavior. Given the tool's importance and 0% schema coverage, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. The description explains 'force' (publish despite readiness blockers), which adds meaning to that parameter. However, 'portalRef' and 'dryRun' are completely undocumented in the description — an agent wouldn't know what portalRef refers to or what dryRun does without inferring from the schema types. With 3 params and 0% coverage, the description should do more.
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 verb+resource: 'Publish a portal'. It also discloses the idempotent nature, which is a distinguishing behavioral trait. Among siblings, it's distinguished from kilango_unpublish_portal (opposite) and kilango_archive_portal, though it doesn't explicitly name the sibling alternatives.
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 mentions 'force=true to publish despite overridable readiness blockers', which gives some context about when force is needed. However, there's no explicit guidance on when to use this vs unpublish/archive tools, and no mention of prerequisites (e.g., does the portal need to exist, be in a draft state?), or what readiness blockers are non-overridable. The idempotent mention is helpful but implied usage overall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false (a write) and destructiveHint=false, but the description adds valuable detail: automatic ETag fetching with If-Match, and the critical widgetInstanceId preservation requirement. It doesn't state failure modes (e.g., what happens on ETag mismatch) or auth requirements, but the If-Match mechanism disclosure is genuinely useful beyond annotation coverage.
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?
Three sentences, dense and information-rich. The structure front-loads the purpose and payload format, then adds the ETag/write mechanism and the critical widgetId warning. No wasted words. Could arguably be slightly more structured with the dryRun caveat, but remains tight and effective.
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 mutating whole-document write with no output schema, more detail would help. The description covers the payload shape and concurrency mechanism but omits: behavior on ETag mismatch, whether dryRun is supported and how it behaves, what the response/return value is, and permission requirements. Given 4 parameters with 0% schema coverage and no output schema, this leaves meaningful gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 for the 4 parameters. The description mentions 'layout' via the Puck payload structure, and that's the primary parameter. However, it does not explain dryRun (boolean defaulting to false), portalRef, or pageRef beyond what the schema names suggest. The field names are fairly self-explanatory, but dryRun's behavior is entirely unexplained, and layout's nested structure is only partially clarified.
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 this tool replaces the whole page layout with a Puck payload, specifying the exact structure (root, content). It distinguishes from other page operations via 'whole-document write' wording. However, the name already conveys 'save page layout' so the added value is moderate, and it doesn't contrast against sibling tools like kilango_update_page.
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 context about when to use this tool (whole-document write, replacing entire layout via ETag If-Match) and warns about behavioral consequences (failing to preserve widgetInstanceId causes the widget row to be recreated). It does not explicitly name alternative tools or say when NOT to use this, but the whole-document framing vs. granular block operations is implied by sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is well-covered. The description adds value by clarifying that deletion also 'drops the stored secret from Kilango's vault,' which is significant behavioral context beyond the annotation — it warns the agent that this is not just removing a config reference but destroying the associated secret. This is genuinely useful supplemental disclosure.
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 a single, compact sentence that front-loads the primary purpose and appends the critical caveat about secret destruction. There is zero waste. Given the simple 2-parameter surface, this length is appropriate.
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 destructive tool with robust annotations (destructiveHint=true) and only one required parameter (provider), the description plus annotations are jointly sufficient. The description notes the vault secret behavior but does not mention effects on dependent resources (e.g., apps using this connection) or the dryRun parameter, which could be relevant. However, for a delete tool with good annotation coverage, this is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (0 paragraphs referencing parameters in the description text); the description mentions 'backend connection' providing context that the provider identifies the connection source, but it does not explicitly describe either the 'provider' or 'dryRun' parameters. However, with only 2 parameters and a reasonably self-explanatory schema (provider = a string with minLength 1, dryRun = boolean defaulting to false), the burden on the description is modest. It partially compensates by framing 'provider' as the target connection, but does not explain the dryRun semantics.
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 uses a specific verb+resource pattern — 'Remove a backend connection' — and adds the important clarifying detail that it drops the stored secret from the vault. This clearly distinguishes it from sibling delete tools (delete_portal, delete_page, delete_content_block) by specifying it targets backend connections specifically. The purpose is unmistakable.
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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention that this is irreversible (beyond the generic destructive annotation), does not reference sibling tools like list_connections or get_connection as prerequisites, and does not state when a user might prefer disconnect vs delete. Given the large sibling family including connect_app, list_connections, and get_connection, this lack of navigation guidance is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, which already establish the safety profile of this as a non-destructive read. The description adds the 'connected workspace' scoping context but doesn't elaborate on what metadata fields are returned or whether results may vary. Since annotations cover the core behavioral traits, credit is given for the added scoping context without heavy burden.
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 one clean sentence with zero wasted words. It front-loads the verb and resource, and every part earns its place. There is nothing extraneous.
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 parameterless metadata retrieval tool with rich annotations (readOnly, idempotent), the description adequately captures its purpose. There's no output schema, so describing the return value shape would be helpful, but for a simple metadata tool the level of completeness is reasonable. It doesn't detail what specific metadata fields are exposed, which is a minor gap.
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?
There are 0 parameters and schema coverage is 100%, so the schema has nothing to document. With no parameters, the baseline is 4; the description doesn't need to explain parameters that don't exist. The description appropriately focuses on what the tool returns rather than parameter meaning.
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 'Return server/tenant metadata for the connected workspace.' This uses a specific verb (Return) and resource (server/tenant metadata for the connected workspace). It's clear what the tool does and distinguishes it adequately from siblings like get_workspace or get_portal, though it doesn't spell out the distinction explicitly.
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 gives a clear context ('for the connected workspace') but doesn't explicitly say when to use this vs alternatives. Since it has no parameters and returns metadata, the usage intent is reasonably implied, but no when-not or alternative guidance is provided despite a large sibling set of get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations fully cover the safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true. The description adds no behavioral context beyond the annotations, but with such complete annotation coverage, re-stating safety would be redundant. Missing details like pagination or return format are not disclosed.
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?
A single, clear sentence with zero filler. For a zero-parameter tool with complete annotations, this level of brevity is appropriate and maximally efficient.
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 zero-parameter read-only listing tool with strong annotations, the description is largely sufficient. It mentions workspace scope which is the key distinguishing characteristic. It could note that this returns workspace-level installations versus portal-level ones, but the sibling list provides that context implicitly.
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?
This tool has zero parameters, and schema coverage is 100% trivially. The description accurately reflects that there are no inputs to document. With no parameters, the baseline jumps to 4 since there's nothing for the description to need to compensate for.
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?
States a clear action (List) on a specific resource (apps installed in the workspace). It distinguishes from siblings like kilango_list_catalog_apps (catalog apps) and kilango_list_portal_apps (portal apps), though it doesn't explicitly name these alternatives. The verb+resource is specific and unambiguous.
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?
Says what it lists (workspace-level installations) which implicitly distinguishes from portal-app and catalog-app listing siblings. However, it provides no explicit when-to-use or when-not-to-use guidance, no exclusions, and no mention of alternatives. The usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating read operation. The description adds the useful behavioral detail that 'Secrets are never returned', which is value beyond the annotations. With annotations covering the safety profile comprehensively, the description's additional disclosure of the no-secrets behavior is adequate but not extensive.
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 two short sentences with zero waste. The first sentence states the core purpose with precise scope, and the second sentence adds one critical behavioral caveat (no secrets). Every word earns its place.
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 zero-parameter, read-only list tool with comprehensive annotations, the description covers the essential scope (workspace-level, one per provider) and a critical caveat (secrets never returned). While it could mention return format or ordering, the simplicity of the tool means little more is needed. The lack of an output schema is somewhat compensated by the 'one per provider' and 'secrets never returned' details.
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?
With zero parameters, the input schema requires no additional documentation. The description meaningfully clarifies the result scope by noting 'one per provider' and that secrets are excluded, which compensates for the absence of an output schema. There is nothing more the description needs to explain about parameters since there are none.
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 uses a specific verb ('List') with a clear resource ('the workspace's backend connections') and adds the 'one per provider' scoping detail, which distinguishes it from related list tools like kilango_list_connectors and kilango_list_portals. It clearly defines the scope as workspace-level and backend connections, which helps differentiate from sibling tools.
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 provides context ('the workspace's backend connections') but does not explicitly state when to use this tool versus alternatives like kilango_list_connectors, kilango_get_connection, or kilango_list_app_installations. There are no when-not-to-use exclusions or named alternatives, leaving the agent to infer usage from the 'one per provider' scoping detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false (mutation expected) and destructiveHint=false, which the description aligns with. The description adds valuable behavioral detail beyond annotations: seedHomePage behavior, the DRAFT status with preview token, and the non-editable slug constraint. It doesn't contradict annotations.
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 concise and front-loaded, with the core action stated first. The behavioral caveats (slug not editable, DRAFT status) are placed efficiently in the second part. No wasted words, though it could benefit from slightly more structure.
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 7-parameter mutation tool with no output schema and 14% schema coverage, the description is moderately helpful. It covers the key creation semantics (DRAFT, preview token, seedHomePage behavior, slug immutability) but omits details about return values, what happens on error, or whether dryRun impacts behavior meaningfully. It explains the most important parameters but leaves several undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is very low at 14%, so the description should compensate. The description does explain what seedHomePage does (creates an 'overblik' page + navigation entry), which adds value. However, the description doesn't explain the kind parameter (references vocabulary tool which is reasonable), name, brandId, or defaultPersonaId, leaving the agent dependent on schema for these.
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 verb (create) and resource (portal in a brand), matching the tool name. It distinguishes from siblings by focusing on creation semantics. However, it doesn't explicitly contrast with update_portal or related tools, though the purpose is evident.
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 communicates key creation context: it starts as DRAFT with a preview token, and slug is not editable after creation. This provides practical guidance about the irreversible nature of slug, though it doesn't explicitly state when-not-to-use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by specifying exactly what data is returned (manifests with appClass, authMode, connectionFields, widgets), clarifying that it reveals app installation/connection requirements. No contradictions found. The description complements rather than repeats the annotations.
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 a single concise sentence that packs useful detail (installable scoping + manifest fields) with no wasted words. It's appropriately front-loaded with the action. Slight room to add the when-to-use context, but for a zero-parameter read tool this is appropriately tight.
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 zero-parameter read-only list tool with strong annotations and no output schema, the description is reasonably complete. It names the resource, scope (installable), and return structure. However, without an output schema, it could benefit from noting the full return shape or count/pagination behavior, and its relationship to kilango_list_app_installations. Minor gaps, but adequate for a simple list operation.
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 0 parameters with 100% schema coverage, so there are no parameters to document. Per the rubric, 0 params = baseline 4, and the description appropriately focuses on what the tool returns rather than input semantics. No param info is needed here.
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 'List installable apps with their manifests' uses a specific verb (List) and resource (installable apps), and specifies the manifest structure returned (appClass, authMode, connectionFields, widgets). It distinguishes from siblings like kilango_list_portals (lists portals) and kilango_list_app_installations (lists installed apps), though it shares a 'list' pattern. A 4 is appropriate since it's clear but doesn't explicitly differentiate from the closely-related kilango_get_catalog_app or kilango_list_app_installations.
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 browsing the app catalog before installation, and the manifest content hints at screening apps. However, no explicit when-to-use/when-not-to-use guidance or alternatives are named. The distinction from kilango_list_app_installations (installed vs installable) and kilango_get_catalog_app (individual vs list) is implicit but not stated, so it's adequate but not directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it's 'Paged with cursor,' which is useful behavioral context not in annotations. However, it doesn't mention pagination limits, default page size, or ordering/return format — with readOnly already covered, a 3 is appropriate.
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?
Two sentences, zero wasted words. Every element earns its place: scope ('workspace'), filter list, pagination mention. Front-loaded with the primary purpose first.
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?
With readOnly/idempotent annotations covering safety and cursor pagination mentioned, the description is reasonably complete for a filtered-list tool with 5 optional params. The parameter semantics are thin but the schema (with status enum) provides some grounding. No output schema exists, so return format isn't required, though a brief note on what fields are returned would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 names all 5 parameters (kind, status, brandId, q, and cursor implied by 'Paged with cursor'), but only by listing them without meaning. The status enum in the schema covers that parameter's values, but kind/brandId/q values are not explained. The description adds nominal value by enumerating filter names but doesn't explain semantics.
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 'List portals in the workspace' — a specific verb+resource. The optional filters (kind, status, brandId, q) help distinguish this from sibling tools like kilango_get_portal (single retrieval) and kilango_list_pages (different resource). It doesn't explicitly differentiate from siblings, but the resource scope and filter list are clear.
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 identifies when to use it — listing portals with filters vs retrieving a single portal. However, it doesn't explicitly state when NOT to use this in favor of, say, kilango_search_operations or kilango_list_portal_apps. The context of listing vs single-get is implied through the sibling names rather than stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare openWorldHint=true and readOnlyHint=false, but the description adds substantial behavioral context: credentials go to vault never through chat (security), one-time browser URL flow, immmediate install for credential-less apps, portal activation behavior, and OAuth exclusion. This is rich behavioral disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences covering all key behavioral aspects with no wasted words. Front-loaded with the core purpose first, then qualification branches. Every sentence adds information: core action, credential flow, credential-less flow, and OAuth exclusion.
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 2 params and no output schema, the description covers the main behavioral paths well: credentialed vs non-credentialed apps, portal activation, and OAuth limitation. Could note whether this is reversible (uninstall_app sibling exists) but given no output schema and moderate complexity, this is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only portalRef is documented in schema). The description explains portalRef's activation effect in the schema, and the description adds context about appKey (it's the app identifier). However, the description doesn't deeply elaborate on appKey validation or format beyond what's in schema. The description adds marginal value for the undecorated appKey param.
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?
Description uses specific verb+resource: 'Install and connect an app to its backend', clearly distinguishing this from sibling tools like install_app and uninstall_app. It covers the core action and the credential-handling nuance, though it doesn't explicitly contrast with the similarly-named sibling install_app.
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?
Clearly explains when to use it, distinguishing behavior for apps with credentials (one-time browser URL) versus without (immediate install). It also states OAuth apps are not connectable yet, providing an exclusion. However, it doesn't explicitly name alternative tools to route around, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description carries minimal burden. The description adds useful context by enumerating the exact manifest fields returned, clarifying authMode semantics (apikey/oauth) and the nature of connectionFields (what a human must supply), which extends value beyond the 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?
A single, dense, front-loaded sentence that lists return fields and their semantics with zero filler. It packs appClass, authMode, connectionFields, and widget structure into one efficient statement.
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 single-parameter read tool with strong annotations (readOnly, idempotent, non-destructive), the return-value enumeration is thorough. No output schema exists, so the description compensates by listing the key manifest fields. It could mention search semantics for appKey or error behavior, but these are minor gaps for a simple catalog read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears full responsibility for explaining the single parameter appKey. However, the description never mentions appKey or explains how to identify which app to fetch. The tool name and sibling naming convention (get_catalog_app vs list_catalog_apps) imply appKey selects a specific app, but nothing in the description compensates for the 0% coverage gap.
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 uses a specific verb+resource ('Return one app manifest') and enumerates exactly which fields it returns: appClass, authMode, connectionFields, and widgets (with widgetKey + renderRole). This clearly differentiates it from siblings like kilango_list_catalog_apps (which lists apps) and kilango_get_app_installation (which retrieves install state rather than the catalog 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 clearly states the return content but does not explicitly tell when to use this vs. alternatives. However, the detailed field enumeration implicitly signals this is for inspecting catalog app definitions/metadata, which a get-tool in a catalog context naturally distinguishes from list or installation tools. No explicit when-not or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive cascade behavior ('Cascades: removes its widgets from all pages') which is critical behavioral context. Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the description's cascade detail meaningfully adds value beyond annotations without contradicting them.
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?
Two compact, information-dense sentences with zero waste. Every clause adds value: the action, the permission requirement, and the cascading consequence.
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?
The annotation set is rich (destructive, non-idempotent, non-readonly), and the description covers the permission gate and cascade behavior well. No output schema means return format guidance would help, but for a straightforward uninstall action the description covers the critical risk factors. The dryRun parameter remains unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for explaining parameters. It explains appKey context implicitly (the app being uninstalled) and the ADMIN key requirement, but it does not explain the dryRun parameter at all, which is a notable gap for a destructive tool where dry-run testing would be valuable.
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 ('Uninstall an app from the workspace') with a specific verb+resource, and even notes it 'Cascades: removes its widgets from all pages.' It does not explicitly differentiate from sibling tools like kilango_deactivate_app_in_portal (which likely deactivates rather than uninstalls), so it misses top marks but is clear about intent.
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 notes 'Requires an ADMIN key' which signals a permission prerequisite. However, it does not explicitly say when to use this vs alternatives like deactivate_app_in_portal or delete_connection. The cascading-destructive nature is implied as a warning, offering partial guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true. The description notes the positional constraint ('at most one of index/before/after') which adds value beyond annotations. However, with no output schema, the description doesn't disclose what the response contains (e.g., the created block's reference ID needed for later updates). The dryRun parameter implies a preview/dry-run behavior that isn't explained in the description.
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?
A single, dense, well-structured sentence. Every element earns its place: the verb+resource, the illustrative examples, the target, and the critical positional constraint. No filler or redundancy.
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?
Given this is a mutation tool with no output schema, no enum constraints on `type` (open-world), and 6 parameters at 0% schema coverage, the description carries significant burden. It conveys the core action and key constraint but doesn't address what the response looks like, what dryRun previews, or what valid `type` values exist beyond three examples. It's adequate but leaves the agent to reason about return contract on its own.
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 clarifies the `position` object semantics (at most one of index/before/after), which is essential. However, it doesn't elaborate on `portalRef`, `pageRef`, `type`, or `props` beyond what names suggest, and with 6 params at 0% coverage the description only partially compensates. The examples of valid `type` values (Heading, RichText, WidgetGrid) are genuinely helpful.
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 what the tool does: 'Add a Hub-native content block (e.g. Heading, RichText, WidgetGrid) to a page at an optional position'. It uses a specific verb (Add) plus resource (content block) plus target (page) and provides concrete examples of block types, distinguishing it from siblings like update_content_block, delete_content_block, and move_block.
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 includes a key usage constraint: 'at most one of index/before/after' for positioning, which is critical guidance. However, it doesn't explicitly state when to use this vs alternative tools like place_widget or when not to use it, though the block types and positioning semantics give reasonable usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds useful behavioral detail: the return shape includes 'blockers' and 'warnings', and each problem carries a code and overridability flag. It doesn't detail what happens on error or how many issues max, but given the annotation coverage, the description contributes meaningful context beyond structured data.
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?
Two sentences, zero filler. It front-loads the return shape, explains what each problem carries, and gives an actionable instruction ('Check before publishing'). Every word earns its place with no 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?
This is a simple read-only tool with one parameter, strong annotations, a clear return shape, and no output schema or nested objects. The description adequately covers purpose, output structure, and usage timing. It could mention how to identify portals (e.g., via kilango_list_portals) for completeness, but for a tool of this complexity the description is near-complete.
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?
With only 1 parameter (portalRef) and 0% schema description coverage, the schema is bare. The description notes it operates 'for a portal', implying portalRef identifies the target. While it doesn't explicitly explain portalRef's format (like whether it's an ID or a reference string), the name itself ('portalRef') plus the description's reference to 'a portal' provides reasonable semantics for a single-parameter tool. The baseline for a 1-param tool with minimal schema coverage and a clear purpose is fairly high.
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 tool returns a readiness assessment for a portal with a specific structure ({ ready, blockers[], warnings[] }). It distinguishes itself from siblings like kilango_get_portal (which presumably fetches portal details) by focusing on 'readiness' for publishing and 'check before publishing' hints at its gatekeeping role. However, it doesn't explicitly name a sibling alternative, though the publish-related sibling (kilango_publish_portal) provides natural context.
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 clear usage context: 'Check before publishing' implies when to use this tool (as a pre-publish gate). This implicitly contrasts with kilango_publish_portal and other get_* tools. It lacks explicit when-not-to-use language or named alternatives, but the publish-context cue is reasonably informative for a read-only checklist tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds meaningful context beyond annotations: the If-Match concurrency semantics, the multi-step fetch-and-reorder behavior, and the renderRole caveat. It doesn't explicitly state side effects or rollback behavior but the mutation is clear. The render tier note is valuable behavioral context that annotations don't cover.
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 tightly-packed sentences with zero waste. Every sentence carries meaning: the operation mechanics, the concurrency approach, the render caveat. Front-loaded with the primary purpose and efficiently layered with implementation and caveat details.
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 compound mutating operation with no output schema, the description is quite complete. It covers the internal multi-step behavior, the concurrency mechanism (If-Match), and the important render-tier nuance. The only minor gap is not describing what the return value is or error conditions, but for a move operation this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It explains the 'position' object shape (index, before, after) and clarifies the semantic for blockId. However, it doesn't detail portalRef/pageRef meanings, and the before/after semantics are implied but not fully elaborated. The description partially compensates for the zero schema coverage but could be more explicit about how before/after resolve into indexes.
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+resource ('Move one block to a new position') and details the position options (index, before/after another blockId). It clearly distinguishes itself from siblings like kilango_reorder_blocks by explaining it handles the multi-step fetch+permutation+reorder flow. The reference to 'render tier' and 'widget renderRole' adds domain-specific clarity.
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 explains the mechanics (fetches current order, computes permutation, calls reorder with If-Match). It provides important context about when visual result may differ from array index. However, it doesn't explicitly mention alternatives like reorder_blocks or state when to use this vs that sibling, which would merit a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false. The description adds meaningful behavioral context beyond annotations: it explains ETag/If-Match concurrency handling with automatic retry on conflict. This is exactly the kind of behavioral nuance the annotations don't convey. Minor gap: it doesn't describe what happens on success (return value) or whether dryRun has side effects.
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?
Two sentences, dense with information. Every sentence earns its place: the first defines the operation and data shape, the second explains concurrency semantics. Zero waste, front-loaded with the core purpose.
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 single-document navigation save with clear entry shape, the description covers the key points: concurrent write handling (ETag/If-Match with retry), entry structure, and whole-document semantics. Missing pieces: return value format, dryRun behavior, and how portalRef is resolved. But given the tool's moderate complexity and clear sibling context (save_page_layout for pages), it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 carry the param meaning. The description explains the navigation entry structure ({ pageSlug, label, icon? }) which overlaps with the schema. However, 'portalRef' is unexplained in the description (it's intuitively the portal reference) and 'dryRun' is never mentioned in the description at all despite being a schema parameter. The description compensates partially but not fully.
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 'Replace' with the resource 'portal navigation tree', and explicitly notes it's a whole-document write. It defines the entry structure ({ pageSlug, label, icon? }). While there's a sibling tool 'kilango_save_page_layout' and 'kilango_get_portal_navigation', the description's emphasis on whole-document replacement and the specific entry schema distinguishes it from page-level layout saving.
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 implies this is for replacing an entire navigation tree (whole-document write) rather than incremental updates, which is useful context given there are related tools like save_page_layout and update_page. However, it doesn't explicitly state when NOT to use this tool or name alternative tools for partial updates, so some context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that deletion requires ADMIN authentication, and that deletion is refused if the portal has pages or accesses unless force=true. These are meaningful behavioral conditions beyond what annotations convey. The description aligns with annotations (destructiveHint=true, readOnlyHint=false), adding valuable context about safety guards and auth requirements. It could mention what happens on force-delete (e.g., whether child pages are cascaded), but the disclosed refusal mechanism is strong behavioral context.
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?
Two crisp sentences with zero waste. The first states the purpose, the second packs critical usage and safety constraints (auth requirement, refusal condition, force override). Highly front-loaded and efficient.
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 dangerous mutation tool with no annotations contradicting, destructiveHint=true properly flagged, and no output schema needed for a destroy operation. The description covers the delete semantics, the force condition, and the dryRun/force params are self-evident from their boolean defaults. With 64 sibling tools including a distinct delete_page (different target), the scope of 'portal deletion' is unambiguous. Slightly incomplete in not explaining what force=true does to child resources, but adequate for the destructive operation 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 description must shoulder the parameter explanation burden. The description references 'force=true' explicitly, explaining the one parameter with meaningful behavioral impact. portalRef is self-evident given the name, and dryRun (defaulting to false) signals a no-op simulation. It doesn't spell out dryRun's effect, but the boolean default and naming make it reasonably inferable.
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?
Specific verb+resource ('Delete a portal') clearly distinct from siblings delete_page, delete_connection, etc. The 'ADMIN' marker in the title and description clarifies the authenticated scope. The description immediately differentiates this from archive_portal, unpublish_portal, and other non-destructive portal operations.
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 states the authPrerequisite (ADMIN key) and the refusal behavior when pages/accesses exist without force=true. This effectively communicates when NOT to call this tool (when portal has children unless force is intended). It doesn't explicitly name alternatives like archive_portal for non-destructive removal, but the destructive semantics paired with the ADMIN marker make the usage boundary reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds the enumeration of what data it returns (brands, portals, personas, apps, providers) which supplements the annotations. However, it doesn't describe the return structure or response format, so it adds some but not rich behavioral context.
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?
Two sentences, zero wasted words. First sentence states the return content, second gives the usage directive. Everything earns its place and is front-loaded with the purpose.
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 parameterless read-only discovery tool, the description is quite complete: it names every data category returned and states the usage context. The only gap is the absence of an output schema and no description of the response shape, which for a data-dictionary tool could matter, but the enumerated categories largely compensate.
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 0 parameters and schema coverage is 100% (there are no params to document). For a parameterless tool, description need not explain params. The description usefully enumerates the categories of data returned, which compensates for the lack of an output 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?
Clear verb+resource: 'Return tenant data to fill argument values'. Names the specific kinds of data (brands, portals, personas, installed apps with widget keys, connected providers) and states its purpose (discover valid ids before creating/editing). Distinguishes well from siblings like kilango_get_meta or kilango_list_portals.
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?
Explicitly says when to use: 'to fill argument values' and 'Use this to discover valid ids before creating or editing.' This clearly signals it's a discovery/lookup tool for id resolution, distinct from the listing and mutation siblings. The 'before creating or editing' phrasing gives a clear usage window.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations beyond readOnlyHint=false and openWorldHint=true. The description adds value by disclosing idempotency and manifest version pinning, which are non-obvious behavioral traits. However, it doesn't mention side effects like whether prior installs get replaced or what changes occur to existing state when dryRun is false. The idempotentHint is false in annotations while description claims idempotency — not a strict contradiction but a nuance worth noting.
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?
Two sentences, front-loaded with purpose, then scoping constraints and alternatives. Zero waste — every clause earns its place. Appends the important negative caveats immediately.
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 two-parameter mutation tool with no output schema, the description covers the core semantics well: idempotency, manifest pinning, visibility caveat, credential alternative. The main gap is the unexplained dryRun parameter and lack of any error/permission context, but for a relatively simple install operation the coverage is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so no parameter-level help in the schema. However, the description explains 'installs pins manifest version' which gives context to appKey (identifies a catalog app). The dryRun parameter is not explained at all — no mention of what a dry run returns or doesn't do. With 0% coverage, the description should do more to compensate for the undocumented parameters.
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?
Clear verb+resource (install an app into workspace), states idempotency and manifest pinning behavior. Explicitly differentiates from kilango_activate_app_in_portal (visibility) and kilango_connect_app (credentials), distinguishing it from relevant siblings.
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?
Explicitly states what installation does NOT do (doesn't make visible, doesn't handle credentials) and directs to the correct alternative tools (kilango_activate_app_in_portal, kilango_connect_app). This gives clear when-to-use and when-not-to-use guidance, and names specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false. The description adds genuine value: it discloses the activation prerequisite and the rendering-note behavior of visual positioning. It warns the agent to read the returned rendering note, which is useful context not present in annotations. It doesn't discuss state changes or side effects explicitly, but the critical caveats are covered.
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 sentences, all earning their place. Front-loads the core action, then immediately follows with the critical prerequisite/error handling, then the behavioral caveat about rendering. Zero filler, no repetition of schema content.
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?
A mutation tool with nested objects (position, config), 7 parameters, and no output schema. The description covers the two most operationally critical behaviors (activation prerequisite and renderRole-based positioning). It could note what the return value represents beyond a 'rendering note,' but given the richness of the annotations and the specific caveats provided, it's reasonably complete for an agent selecting and invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 7 parameters, so the description must compensate. It explains the semantic of position (index vs renderRole tier, not necessarily top of page) and mentions config implicitly via widget placement. However, it doesn't clarify what portalRef/pageRef/appKey/widgetKey refer to or how dryRun behaves, leaving some parameters ambiguous despite the good positioning context.
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?
Clear specific verb+resource: 'Place an app widget on a page.' Distinguishes from siblings by naming the exact action and objects involved. Differentiates from related tools like kilango_add_content_block, kilango_update_widget, kilango_move_block, and kilango_reorder_blocks because it specifically addresses placing a widget.
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?
Explicitly states a key prerequisite: 'The app must be installed AND activated in the portal first' and names the specific error (app_not_activated_in_portal) along with the fixing call. Also provides behavioral context about how visual position works ('index 0 is not necessarily top of page'), guiding the agent on interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds that it's sent with If-Match (concurrency control), which is valuable operational context beyond the annotations. It doesn't describe what happens on failure/conflict, but the If-Match mention partially covers this. The openWorldHint=true suggests external systems may be involved, and the description doesn't elaborate, but the If-Match detail 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The language is direct and front-loaded with the core action, then adds constraints. Every clause earns its place.
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?
The tool is a simple mutation with 3 params and no output schema. The description covers the essential purpose, the critical constraint (complete permutation), and the concurrency mechanism. It's reasonably complete for a straightforward reorder operation, though it could optionally mention how to retrieve current block order (via get_page_blocks) as a prerequisite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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. The description clarifies that 'order' must be a complete permutation of existing blockIds, which is essential semantic info. However, portalRef and pageRef are not explained beyond being string refs, and the relationship between the 'order' array items and existing block IDs, while implied, isn't fully specified in terms of what IDs to source from.
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+resource: 'Set the full block order on a page.' It clearly differentiates from its sibling kilango_move_block (single-block move) by emphasizing 'full block order' vs incremental moves, which is a key distinguishing factor given the sibling list includes both.
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 explicitly states usage constraints: 'order must be a complete permutation of every existing blockId (no adds/drops).' This is critical guidance that prevents misuse. It also implies when to use this vs the 'move_block' sibling (full reorder vs single move), though it doesn't name the alternative explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered by structured data. The description adds the useful context that it searches a specific API contract (openapi.json) and returns operationIds for use with a companion tool. With strong annotations in place, a 3 is appropriate since the description adds some context but doesn't disclose return format details like how many results, pagination, or how to interpret results beyond operationIds.
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?
Two sentences, zero wasted words. The first sentence states the action and source; the second sentence states what it returns and how to use it. Every clause earns its place.
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?
Given this is a relatively simple search tool with only 2 parameters (both optional with defaults), strong annotations, and no output schema, the description is largely complete. It explains the purpose, source, and downstream flow. It could benefit from mentioning what the results look like (e.g., list of operationIds vs JSON), but the description already states 'returns operationIds', which is a sufficient return contract. A 4 reflects the minor gap around result formatting/pagination.
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 for the two parameters (query, limit). The description implies the 'query' parameter is the search term ('Search the full operator API contract...'), and 'limit' has a schema default. However, it doesn't explicitly describe what a query string should contain (e.g., free text vs operationId fragment), but the description's framing of 'search' makes the query semantics reasonably inferable. Given zero schema coverage, the description does partial compensation work, warranting a 4.
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 searches the full operator API contract (from /v1/openapi.json) for operations not covered by a curated tool, and returns operationIds usable with kilango_call_operation. The verb 'search' + specific resource (operator API contract) + scope ('operations not covered by a curated tool') is specific and distinguishes it from siblings like kilango_describe_operation.
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 explicitly states it searches for operations NOT covered by a curated tool, which tells the agent when to use it (when a desired operation has no dedicated sibling tool). It also explains the output is usable with kilango_call_operation, establishing the workflow relationship with its sibling. This is clear usage guidance with implicit exclusions for curated operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds context about what the workspace reveals (read vs write, ADMIN scope), which is useful beyond the annotations. No contradiction. It doesn't over-disclose beyond what's useful.
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?
A single, information-dense sentence plus a clear call-to-action. Zero wasted words. Front-loaded with action and resource, immediately followed by what it returns and when to use it.
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, read-only metadata/discovery tool with rich annotations, this description fully covers purpose, use case, and expected output. No output schema exists, but it implies return contents (workspace, role/scopes). Nothing material is missing.
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?
Zero parameters, so baseline is 4 according to the rubric. Schema has no params to document, and the description doesn't need to add param semantics. The description's mention of role/scopes output is a nice forward-looking hint about what will be returned.
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?
Specific verb 'get' + resource 'workspace', clearly states what it returns (bound workspace plus key role/scopes). Distinguishes itself as a discovery/context tool from siblings that all operate on portals, pages, or operations.
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?
Explicitly instructs to 'call this first to confirm which workspace and what capability you have.' This is strong when-to-use guidance and implies it's a prerequisite before other operations, especially distinguishing read vs write/ADMIN capability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds value by explaining what specific information is returned (If-Match requirement, write status) that an agent would need to know before invoking an operation. Notable that no output schema exists, so the description carries the burden of explaining the return shape, which it does reasonably well.
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?
Single dense sentence that enumerates all return fields and adds the usage directive. Zero wasted words, highly efficient front-loading of purpose.
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 metadata-lookup tool with one parameter and no output schema, the description covers the essential return fields and use context. It could arguably mention how the operationId is obtained (e.g., from kilango_search_operations) or what 'write' means for the caller, but given the tool's simple nature, the current description is largely sufficient. The sequential relationship with call_operation is the most important contextual fact and it's present.
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?
There is only 1 parameter (operationId) with 0% schema description coverage. The description references 'a given operationId' which clarifies the parameter's purpose as an identifier for a specific operation, but doesn't elaborate on its format or source (e.g., how an agent obtains a valid operationId, perhaps via kilango_search_operations). Still, for a single self-evident string parameter, the description provides adequate context.
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 it returns specific metadata (method, path, params, If-Match requirement, write status) for a given operationId. It uses a specific verb ('Return') with a distinct resource (operation metadata), and differentiates itself from the sibling kilango_call_operation by explicitly saying 'Use before kilango_call_operation'.
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?
Explicitly states when to use it ('Use before kilango_call_operation'), establishing a clear sequential workflow. It positions this as a prerequisite/discovery tool that should precede the execution tool, which is excellent guidance for agent routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations covering readOnly/destructive/idempotent hints, the description adds substantial behavioral context not in annotations: the If-Match ETag auto-fetch behavior, write-gating via KILANGO_ENABLE_WRITES and API key scopes, and that it's an escape hatch. Annotations mark openWorldHint=true and readOnlyHint=false; description's statement that mutating calls are gated aligns and adds crucial detail about those gates. dryRun and idempotencyKey params imply simulation and retry semantics that the description contextualizes well.
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?
Four tight sentences, each earning its place: what it does, how to discover ids, how to structure input, and key safety gating. No fluff, no repetition of schema content. Front-loaded with the purpose in the opening line.
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 generic escape-hatch with open-world semantics, the description covers the essential usage contract: discovery mechanism, input structure, If-Match behavior, and write-safety gating. No output schema exists, so return format isn't described, but for a fully generic passthrough tool the return shape is inherited from the target operation which the agent discovers via kilango_describe_operation. Some could argue it should note error/response patterns, but this is near-complete.
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 only 17%, so the description carries much of the burden. The description explains operationId (discover via sibling tools), path/query/body separation, and mentions dryRun indirectly through 'Mutating calls are gated'. However, dryRun, idempotencyKey, and body are not individually explained in prose - the description describes the structure ('provide path params, query, and body separately') but doesn't explain what dryRun or idempotencyKey do beyond what the schema's default/minLength hints suggest. Still, given 5 untouched schema params this is stronger than baseline.
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 is explicit: 'call any operator API operation by its operationId', framing itself as an 'escape hatch'. It clearly distinguishes from the many specific sibling tools (get_portal, update_portal, etc.) by positioning itself as the generic catch-all for operations not covered by wrappers.
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 it ('escape hatch' for operations not otherwise exposed), how to discover ids (kilango_search_operations / kilango_describe_operation), how to structure input (path/query/body separately), and important conditions (If-Match auto-handling, write gating by KILANGO_ENABLE_WRITES and API key scopes). This is model guidance for a generic passthrough tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-kilango MCP server](https://glama.ai/mcp/servers/borgels/mcp-server-kilango/badges/card.svg)](https://glama.ai/mcp/servers/borgels/mcp-server-kilango)

Score Badge

Copy to your README.md:

[![mcp-server-kilango MCP server](https://glama.ai/mcp/servers/borgels/mcp-server-kilango/badges/score.svg)](https://glama.ai/mcp/servers/borgels/mcp-server-kilango)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/borgels/mcp-server-kilango'

If you have feedback or need assistance with the MCP directory API, please join our Discord server