Spala Public MCP

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

Annotations already indicate a destructive write operation (readOnlyHint: false, destructiveHint: true). The description adds that it writes 'missing account data' and only creates an organization 'when none exists,' suggesting it fills gaps without overwriting existing values or duplicating orgs. This provides behavioral context 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.

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

The description is a single, efficient sentence with the critical warnings ('AUTH REQUIRED; WRITES...') front-loaded in caps. Every clause contributes to understanding the tool's purpose and usage without redundancy.

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

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

Given the presence of an output schema, return-value explanation is not needed. The description covers purpose, conditions, and authentication requirements, while the schema covers parameter-specific semantics. It could be more complete by explicitly referencing account_status as the source of missing-field information, but the schema mentions this, making the tool adequately documented.

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

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

The input schema has 100% coverage, with each parameter explicitly describing its conditional requirement (e.g., 'Required when account_status reports lastName missing'). The main description only adds a general note about using real values, which is already echoed in the schema's bottom description. Thus, the description adds no significant meaning beyond the schema.

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

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

The description clearly states the tool's action: 'Fills missing first and last name fields and creates the first company or workspace organization when none exists.' This specific verb+resource statement distinguishes it from read-only siblings like account_status and from organization_create by noting it creates the 'first' organization.

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

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

The description provides clear context for when to invoke: 'Invoke only with real account and organization values supplied by the user' and 'AUTH REQUIRED.' It implies conditional use when account data is missing, but it does not explicitly exclude alternative tools like account_status for checking or organization_create for additional orgs, so it lacks explicit when-not guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral context: it returns authenticated identity, organizations, and missing fields, and explicitly states it does not expose credentials. This goes beyond what annotations provide.

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

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

Two sentences, with the first sentence front-loaded with critical qualifiers (AUTH REQUIRED; READ-ONLY). Every phrase adds value, and it is appropriately compact for a no-argument tool.

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

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

Given there is an output schema and no parameters, the description sufficiently explains the return values (identity, organizations, missing fields) and safety behavior (no credential exposure). It is complete for the tool's scope and complexity.

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

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

The tool has zero parameters; the schema already specifies 'No arguments' and the description repeats that. Per the rubric, zero params gets a baseline of 4, as there is no parameter complexity to elaborate on.

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

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

The description uses a specific verb and resource: 'Verifies the current public MCP OAuth identity and account readiness.' It clearly states what the tool does and differentiates it from siblings like account_setup by focusing on status verification rather than setup.

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

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

The description implies usage for checking account readiness before other operations but does not explicitly state when to use vs alternatives or provide any exclusions. It mentions AUTH REQUIRED and READ-ONLY, which gives some context, but lacks direct guidance on choosing this over account_setup or other tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context: it specifies the resource is 'public', lists example capabilities (webhooks, outbound HTTP, etc.), and notes that results match an 'optional query'. This goes beyond annotations and schema by clarifying the tool's domain scope.

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

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

The description is two sentences, front-loaded with the primary action and resource, followed by a use-case invitation and return fields. Every clause adds value with zero redundancy, making it highly concise and well-structured.

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

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

The tool has an output schema, so return values are structurally defined, but the description also mentions the key return fields, reinforcing them. With only two optional parameters, a clear use case, and safe read-only annotations, the description covers all necessary context for correct invocation.

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

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

Schema coverage is 100%, with both 'limit' and 'query' described in detail. The description mentions 'matching an optional query' and 'list' but adds no new meaning beyond the schema's existing parameter descriptions. Baseline 3 is appropriate.

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

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

The description clearly states the tool 'Lists public Spala addons and integrations' with an optional query, and distinguishes this from sibling tools like template_list by specifying addons/integrations. It also enumerates return fields (ids, names, descriptions, tags), making the verb+resource+scope unambiguous.

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

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

The description explicitly states when to use it ('Invoke to discover capabilities such as...'), giving a clear use case. It doesn't mention alternatives or when-not-to-use, but the resource scope (addons vs templates) and sibling names provide context. No exclusions are needed for a list/read operation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about the scope (public index) and return format (ranked entries with URLs and summaries), which goes beyond the annotations. No hidden side effects are revealed, but the annotations cover safety.

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

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

Two concise sentences: first states the function, second provides usage guidance. No filler, front-loaded with the primary purpose.

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

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

With output schema present and strong annotations, the description covers purpose, usage scenarios, and return value shape (ranked docs with URLs and summaries). It is complete for a straightforward search tool.

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

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

Schema description coverage is 100%; both query and limit are described in the schema. The description does not add significant parameter-level detail beyond the schema, as the schema already lists example query terms. Baseline 3 is appropriate.

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

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

The description clearly states it searches the public Spala agent-facing documentation index by query, which is a specific verb+resource. It also lists concrete topics (setup, OAuth, installer, MCP, pricing, etc.) that distinguishes it from sibling tools like spala_help or project management tools.

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

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

Provides explicit usage context by listing question types that should trigger this tool ('Invoke for setup, OAuth, installer...'). It does not explicitly name alternative tools or state when not to use it, but the topic list gives clear guidance for an agent.

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

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

Annotations already indicate write and destructive behavior. The description adds context that this is for the signed-in account and creates an 'additional' organization, which is useful beyond the annotations. No contradiction exists.

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

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

The description is two sentences, front-loaded with the critical auth and write intent, and contains no wasted words.

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

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

For a simple one-parameter tool with an output schema present, the description fully covers purpose, auth requirement, and effect. No additional information is necessary.

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

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

Schema description coverage is 100% and the name parameter is well-documented in the schema. The description only says 'using the supplied name' without adding extra semantics, matching the baseline for high schema coverage.

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

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

The description uses a specific verb ('WRITES'/'Creates') with a clear resource ('Spala organization') and scope ('for the signed-in account', 'additional company or workspace'). This clearly distinguishes it from sibling tools like project_create or spala_start.

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

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

The description provides clear context: it is for creating an additional organization for the signed-in account, and notes that auth is required. However, it does not explicitly name alternatives or state when not to use this tool, though the sibling list implies it is the org-creation tool.

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

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

The description adds substantial behavioral context beyond the annotations: it flags auth requirement, states idempotency explicitly, describes the client-omission result, and details the two bootstrap modes (protected one-time vs verifier-bound delegated). This enriches the agent's understanding of side effects and special cases without contradicting 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.

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

The description is concise at three sentences, front-loaded with 'AUTH REQUIRED; IDEMPOTENT PROJECT CONNECTION WRITE.' Each sentence delivers distinct, essential information without filler or redundancy. The structure effectively highlights the tool's critical attributes.

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

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

For a tool with 6 params, oneOf selectors, and a complex flow, the description covers the core purpose, return type, and client selection edge case. The schema and output schema fill remaining details like parameter syntax and return structure, so the description is sufficiently complete. It could be improved by explicitly mentioning the prerequisite of a prepared project (bootstrapChallenge), but that is implied via schema.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal parameter-specific guidance beyond restating 'installer client' and omission behavior, which is already in the client property description. It earns the baseline 3.

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

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

The description uses a specific verb+resource ('Prepares one accessible Spala project for agent access') and clearly identifies the deliverable (client-specific workspace binding plan). It distinguishes itself from siblings by referencing installer clients and the project connection flow, making its unique role clear.

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

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

The description gives clear context on when to use the tool (preparing a project for agent access) and describes behavior when the client is omitted. It doesn't explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer appropriate usage.

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

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

The description adds 'AUTH REQUIRED' and 'WRITES TO THE SPALA CONTROL PLANE', which are not captured by the annotations. It also explains auto-scoping behavior for a sole organization. These traits go beyond the structured annotations and significantly enhance transparency.

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

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

The description is three sentences, front-loaded with the critical auth/write warning, followed by purpose and behavior. Every sentence contributes value with no redundancy or filler.

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

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

For a creation tool with output schema and annotations, the description covers the essential aspects: auth, write side effect, organization scoping, and non-idempotency. It lacks explicit alternative tool mentions, but the overall context is nearly complete.

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

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

Schema description coverage is 100%, so the parameters are already well-documented. The description restates the organizationId condition but adds no new format or syntax details beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Creates' and resource 'a real Spala project', with specific scoping to 'an accessible organization'. It distinguishes itself from siblings like project_list and project_connect by emphasizing real creation in the control plane.

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

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

The description gives clear context on when to pass organizationId ('when multiple organizations are available') and that a sole organization is auto-scoped. However, it does not explicitly mention alternative tools for listing or connecting to projects, so it lacks explicit when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=true. The description adds auth requirement and idempotency, and clarifies that omitting client returns a non-executable response. But it does not explain what the 'write' modifies or what destructive side effects might occur, leaving destructiveHint ambiguous.

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

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

Two sentences, front-loaded with key qualifiers ('AUTH REQUIRED; IDEMPOTENT PROJECT CONNECTION WRITE'), and no redundant or filler content.

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

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

Given the rich schema (oneOf, 6 params, output schema), the description covers essential aspects: auth, idempotency, write nature, client selection, and return content. It doesn't explain selector exclusivity or bootstrap params, but those are fully documented in the schema.

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

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

Schema description coverage is 100%, so baseline is 3. The description reiterates the client omission behavior already present in the schema and provides no additional semantic detail beyond that.

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

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

The description clearly states a specific verb ('prepares and returns') and resource ('project MCP manifest URL, MCP URL, and client-specific workspace binding plan'). It distinguishes itself from siblings like project_get_public_context by focusing on MCP manifest retrieval and installer client behavior, including the omitted-client fallback.

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

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

Provides clear context: auth required, idempotent write, accepts one installer client, and explains omitted-client behavior. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusion guidance.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful context beyond this by specifying that the tool does not expose tokens, private source code, unrelated customer data, or executable installer arguments, and that auth is required. This supplements the 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.

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

The description is a single sentence, front-loaded with 'AUTH REQUIRED; READ-ONLY,' and every phrase earns its place. It is concise without sacrificing key information.

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

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

With a comprehensive schema (including oneOf selector) and an output schema present, the description covers the core purpose and safety exclusions. It does not repeat return-value details or selector rules, which are already in the schema. Minor room for improvement: it could explicitly mention that exactly one of projectId or subdomain is required, but that is covered structurally.

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

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

Schema description coverage is 100%, so the schema fully documents projectId, subdomain, and organizationId, including mutual exclusivity. The description does not add parameter-specific meaning, so it meets the baseline but does not go beyond it.

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

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

The description uses a specific verb ('Returns') and identifies the resource ('documented MCP handoff fields for one accessible project'). It clearly distinguishes this from sibling tools by focusing on public context retrieval and explicitly listing exclusions, making the purpose unambiguous.

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

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

The description implies usage context (retrieving public context for a project) and notes auth requirements, but it does not explicitly mention alternatives or when not to use this tool. Sibling tools like project_select or project_get_mcp_manifest exist, but no exclusions or comparisons are provided.

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

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

The description adds 'AUTH REQUIRED' (not covered by annotations) and explains automatic organization scoping behavior. It also states 'READ-ONLY' which aligns with the readOnlyHint annotation but adds no contradiction. The added context about auth and scoping goes beyond what annotations provide.

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

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

The description is two sentences, front-loaded with 'AUTH REQUIRED; READ-ONLY' followed by a clear statement of function and scoping behavior. Every sentence earns its place with no redundancy or filler.

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

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

The tool has a single optional parameter, and the description covers auth, read-only nature, and organization scoping. An output schema exists, so return values need not be described. The description is fully adequate for this low-complexity tool.

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

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

Schema description coverage is 100%, so the parameter is well-documented. The tool description reinforces the conditional nature of organizationId ('Accepts an organization id when multiple organizations are available'), adding meaning about when to pass the parameter versus letting it be inferred.

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

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

The description uses a specific verb ('Lists') and resource ('projects accessible to the authenticated Spala user'), and clarifies the organizational scope. It distinguishes itself from sibling tools like project_create, project_select, and project_connect by focusing on listing.

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

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

The description clearly explains when to supply an organizationId ('when multiple organizations are available') and that a sole organization is automatically scoped. It does not explicitly name alternatives or exclusion cases, but the scoping guidance provides useful context for when this tool is appropriate.

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

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

Beyond annotations (readOnlyHint=false, idempotentHint=true), the description adds 'AUTH REQUIRED', clarifies it is a write operation, and mentions it returns a binding contract. It doesn't contradict annotations. It could elaborate on side effects given destructiveHint=true, but annotations already provide that signal.

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

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

Two compact sentences front-load key traits (auth, idempotency, write, alias) and then specify the exact purpose. No wasted words.

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

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

The description captures the essential behavior: auth required, idempotent write, alias relationship, and what it returns. With an output schema and rich annotations, it doesn't need to detail return structure or error conditions. Missing a bit on the bootstrap interaction, but schema covers that.

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

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

The schema has 100% coverage with detailed descriptions for all parameters (e.g., mutual exclusivity of projectId/subdomain, bootstrap fields). The description adds no parameter-specific details, so baseline 3 is appropriate.

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

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

The description clearly states it's an idempotent project connection write, a compatibility alias for project_connect, and what it does: prepares one accessible project and returns the binding contract. This distinguishes it from siblings by explicitly referencing project_connect as the original.

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

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

The description gives clear context: auth required, idempotent, compatibility alias for project_connect. It implies interchangeability with project_connect and that it prepares an accessible project. However, it doesn't provide explicit exclusion criteria or when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description adds useful context by specifying the exact content returned (product scope, OAuth metadata, workflow stages, canonical links). This goes beyond the schema and annotations.

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

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

The description is a single sentence that front-loads the core purpose ('Returns machine-readable...') and packs meaningful details without redundancy. Every phrase adds value.

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

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

For a no-argument, read-only tool with an output schema, the description fully covers what the tool provides. It lists the content categories and format (machine-readable), making it self-sufficient for an agent to understand the tool's purpose and results.

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

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

The input schema has zero parameters and no arguments are needed. Per the baseline rule for 0-param tools, the description is not required to elaborate on parameters, and it correctly makes no misleading parameter claims.

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

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

The description uses a specific verb ('Returns') with a clear resource ('machine-readable Spala onboarding information') and explicitly lists contained items (product scope, OAuth metadata, etc.), which distinguishes it from siblings like spala_get_tool_map or spala_help.

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

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

Usage is implied by the name and 'onboarding information' but the description does not explicitly state when to use this tool versus alternatives or provide any exclusion scenarios. It simply describes what the tool returns.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by listing what the map identifies, but does not disclose additional behavioral details like whether authentication is required or if the response is cached. There is 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.

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

The description is two sentences, front-loaded with the primary purpose. The first sentence states what it returns; the second lists the categories of information. Every phrase earns its place with no redundancy or fluff.

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

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

Given zero parameters, an output schema defining the return format, and annotations covering safety, the description is complete. It explains the tool's purpose and content sufficiently for an agent to select and invoke it correctly without needing further elaboration.

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

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

The tool has zero parameters, and the schema description clearly states it expects an empty object. With 100% schema coverage and no parameters to explain, the description does not need to add parameter details. The baseline score of 4 for zero-parameter tools applies.

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

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

The description clearly states the tool returns a machine-readable routing map for Spala MCP clients and enumerates the specific content categories (public/authenticated tools, installer clients, OAuth endpoints, handoff rules, entry points). This specific verb+resource scope distinguishes it from sibling tools like spala_help or spala_get_onboarding.

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

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

The description implies usage: when you need a routing map containing tool classifications and endpoints, this is the tool. It provides clear context about what the map includes, but does not explicitly state when not to use it or mention alternatives such as spala_help. Since no exclusions are given, it stays at a 4.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'requires no authentication' and 'does not access or modify project data,' providing stronger guarantees beyond the basic hints. This additional context is valuable and does not 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.

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

The description is two sentences long, with the first sentence front-loading the core purpose and the second providing usage and safety context. Each sentence earns its place, with no redundant or filler content.

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

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

For a simple no-parameter help tool with a rich output schema and good annotations, the description covers the essential aspects: what is returned (overview, URLs, boundary), when to use it (orientation), and its safety profile (read-only, no auth, no project access). This is sufficient for an agent to select and invoke it correctly.

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

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

The tool has zero parameters, so the baseline is 4. The schema already states 'No arguments' and the description adds no param-specific details, but no such details are needed. The description's focus on output and usage compensates for the lack of parameters.

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

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

The description clearly states the tool 'Returns a human-readable overview of Spala, canonical start URLs, and the boundary between public discovery and project-scoped backend MCPs.' This is a specific verb+resource and distinguishes it from sibling tools like docs_search or spala_get_tool_map by focusing on orientation and boundary clarification.

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

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

The description provides a clear invocation context: 'Invoke for product, setup, or integration orientation.' It does not explicitly mention alternatives or when not to use the tool, but the context is specific enough for an agent to know when this help tool is appropriate.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds valuable behavioral details: reports missing account fields, auto-scopes a sole organization, and returns all accessible choices with multiple organizations. These specifics help the agent understand side effects and decision logic.

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

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

The description is two dense sentences with the key qualifier 'AUTH REQUIRED; READ-ONLY STARTUP' front-loaded. Every clause adds value, covering purpose, usage, and behavioral nuance without redundancy.

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

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

Given the output schema exists and there are no input parameters, the description fully covers the tool's context: when to invoke, what it returns, and how it handles single versus multiple organizations. No significant gaps remain for an agent to invoke it correctly.

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

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

The tool has zero parameters, and the schema clearly states 'No arguments.' With no params to describe, the baseline is 4, and the description does not need to add parameter meaning. It correctly focuses on output behavior.

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

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

The description clearly states the tool's purpose as a startup routine to begin Spala account or project setup after OAuth. It distinguishes itself from siblings by emphasizing 'READ-ONLY STARTUP' and returning a versioned startup phase, which is a unique entry-point function.

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

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

It explicitly specifies when to use the tool ('Invoke after OAuth to begin Spala account or project setup'), providing clear context. However, it does not explicitly mention alternatives or when not to use it, so it lacks the full 5-level guidance of naming sibling alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, establishing a safe read operation. The description adds that it lists public templates and returns specific fields (ids, names, descriptions, tags), providing useful behavioral context 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.

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

Three sentences, with the core statement first. The middle sentence adds useful context with examples, and the last sentence discloses return contents without redundancy.

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

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

With an output schema present and only two optional parameters, the description is sufficient. It covers what the tool does, when to use it, and what it returns, making it complete for this simple list operation.

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

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

The schema covers both limit and query with descriptions, achieving 100% coverage. The description mentions 'optional query' but does not add any parameter semantics beyond what the schema already states, so baseline 3 applies.

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

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

The description starts with 'Lists public Spala backend templates matching an optional query,' clearly identifying the action and resource. It distinguishes from siblings like addon_list by focusing on templates and providing examples of backend starting points.

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

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

It provides context for when to use: 'to discover available backend starting points.' It does not explicitly mention alternatives or when not to use, but the focus on public templates and examples makes the use case clear.

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