BrunoSan Intelligence Concierge

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

With no annotations, the description carries the behavioral disclosure burden. It clearly states this is a return-only discovery operation and lists the output categories, including access summary and next actions. It does not explicitly state side-effect safety or access prerequisites, but a zero-parameter discovery tool is already well characterized.

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 front-loaded with 'Start here' and uses three compact sentences with no filler. Every clause adds value: purpose, returned content, and why it is richer than a directory.

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 empty input schema and no output schema, the description covers the main categories an agent needs: domains, LENS layer, endpoints, documentation, doctrine, access, and next actions. It could be more explicit about return format or error behavior, but for a discovery entry point it is sufficiently complete.

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

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

The tool has zero parameters and an empty schema, so the baseline is 4. The description correctly focuses on what the tool returns rather than attempting to document nonexistent 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 opens with 'Start here' and 'understand the complete BrunoSan Intelligence network', giving a specific purpose and resource. It enumerates the returned content and explicitly contrasts itself with a directory, distinguishing it from sibling list_intelligence_domains.

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?

'Start here' clearly establishes this as the entry point for deciding whether BrunoSan can satisfy a goal. It does not explicitly name sibling alternatives to avoid, so it falls short of full when/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?

With no annotations, the description carries the full burden of behavioral disclosure. It discloses that no price is embedded in the server and that absent manifest values stay absent rather than being estimated — a useful behavioral trait about data provenance and handling of missing values. It does not explicitly state read-only behavior, but the absence of side effects and the 'Return' wording imply it.

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 with no filler. The primary purpose is stated first, and the behavioral note about estimated values is supplementary. Every sentence earns its place.

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

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

For a zero-parameter tool, the description is adequate. It specifies the source (shared manifest) and the behavior for missing values. It does not detail the output structure, but given the lack of an output schema and the simplicity of the tool, this is a minor gap. The agent can call it without ambiguity.

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 coverage is 100% (empty). Per the rubric, a tool with 0 parameters gets a baseline of 4. The description adds nothing about parameters because there are none, which 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 action (Return) and the specific resource (BrunoSan access and pricing from the shared pricing manifest). It is distinct from sibling tools that focus on intelligence, domain inspection, or connection info, so the agent can identify its purpose unambiguously.

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 context (that pricing comes from a shared manifest) but does not explicitly state when this tool should be used versus alternatives, nor does it mention any exclusions. Usage is implied rather than expressed.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that results are canonical and not client-specific guesses, but does not mention whether the operation is read-only, requires specific permissions, or what the return structure looks like. Significant gaps remain for a read-like tool.

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

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

A single sentence with zero waste. The core purpose and constraint ('without guessing client-specific config') are front-loaded, making it immediately scannable.

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 low complexity (one parameter, no output schema) and the parameter description already embedded, the description is minimally adequate. However, with multiple sibling tools and no guidance on how this differs from inspect_domain or get_access_options, an agent may not know when this is the right choice. Some additional context about what 'connection details' encompass would improve completeness.

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

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

Schema coverage is 100% and the domain parameter already has a clear description ('BrunoSan domain id/name whose canonical MCP connection should be returned'). The tool description does not add any meaning beyond what the schema provides, so the baseline score of 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 states a clear verb ('Return') and a resource ('canonical connection details') while explicitly clarifying that it does not guess client-specific config. This distinguishes it from sibling tools like get_access_options or inspect_domain, though the exact content of 'connection details' remains somewhat vague.

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 that this tool provides canonical, authoritative connection info, but it does not explicitly state when to use it instead of siblings like discover_brunosan or get_access_options. No alternatives or exclusions are mentioned.

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?

With no annotations present, the description carries the behavioral disclosure burden and does so well: it explains that this is a non-executing health check, that it probes initialization and tool listing, and that it does not speak to data freshness. It could add detail about the short-lived cache or response shape, but the core behavior is clear.

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 front-load the main purpose and immediately add the critical scoping limitation. Every sentence earns its place and there is no redundant wording.

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 health-check tool, the description covers what the tool does, what it does not do, and its limitations. It lacks an explicit description of the return shape, but the stated purpose sufficiently implies per-MCP initialization and tool-listing status.

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

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

Schema coverage is 100% and the single optional parameter is already documented well in the schema, including its default and purpose. The description adds no parameter-specific meaning, but it does not need to because the schema is sufficient.

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

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

The description states a specific verb and resource: it checks whether each canonical BrunoSan MCP initializes and lists tools. It further clarifies this is a capability-plane health check, which separates it from the intelligence-execution scope of sibling 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?

The description clearly frames when to use this tool: for capability-plane health checks only. It also provides exclusions, stating it does not execute protected intelligence tools and makes no claims about data freshness, though it does not explicitly name alternative 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?

With no annotations, the description carries the behavioral burden and does well by listing the returned fields and calling out the default inclusion of the live tools/list inventory. It makes clear this is an inspection/read operation, though it does not discuss authorization, caching, or failure behavior.

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 compact, front-loaded with the core purpose, and uses a concise bullet-like return list. Every sentence adds value without redundancy.

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

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

Given there is no output schema and no annotations, the description provides enough return-value context for an agent to understand what the tool produces. It could go slightly further by noting how to discover valid domain values, but the schema supplies examples and the sibling list suggests other discovery tools.

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 both parameters. The description adds context about the default live inventory but does not add significant meaning beyond the schema's own parameter descriptions.

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

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

The description states a specific verb, 'Open one BrunoSan vertical,' and clarifies it returns a complete capability object. It is clear about the resource and scope, though it does not explicitly contrast with sibling tools like inspect_tool or list_intelligence_domains.

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 this tool is for inspecting a single vertical and enumerates what it returns, giving helpful context. However, it does not explicitly state when to prefer this over alternative tools or mention any exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that it does not execute the tool and never requests or forwards an API key, which are critical safety behaviors. It also mentions the return type (domain, description, schema). This is strong transparency for a meta-tool that only inspects.

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 concise sentences with no wasted words. The primary purpose and safety caveats are front-loaded, making it easy for an agent to quickly grasp what the tool does and its boundaries. Every sentence 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?

The description covers the core function, return values, and key safety constraints. There is no output schema, but it clearly states what information will be returned (domain, description, input schema). It does not mention error cases or partial-match behavior for tool_name, but for a simple inspection tool this is acceptable. Overall, it provides sufficient context for an agent to call it correctly.

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

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

Schema description coverage is 100%, so both parameters are fully described in the schema (tool_name: exact or partial name; domain: optional restriction). The description itself does not add any additional parameter context beyond what the schema already provides. Since the schema covers the semantics completely, a baseline score of 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 'Find and inspect' with a specific resource ('one underlying vertical MCP tool'), and details what is returned (owning domain, live description, input schema). It distinguishes itself from siblings by explicitly stating it does not execute the tool and never requests API keys, which sets it apart from execution or connection tools. This is a precise and unambiguous purpose.

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 metadata about a tool before invoking it, this is the tool to use. It also clarifies what it does not do (execute or forward keys), which indirectly signals when to avoid it. However, it does not explicitly name alternatives or provide 'when not to use' conditions, but the context is clear enough.

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?

With no annotations provided, the description carries the burden of disclosing behavior. It does this well by explaining the default SSOT-only operation and the live probing behavior when include_live_tool_counts=true. It doesn't cover potential latency, permissions, or edge cases, but it gives meaningful behavioral context beyond a bare list operation.

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 and well-structured: one sentence states the tool's purpose, and the second sentence explains the default behavior plus the conditional flag. There is no filler or redundant information.

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

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

For a simple list tool with one optional parameter and no output schema, the description is nearly complete. It explains the default and the flag, but it could be slightly clearer about what an 'intelligence authority' is and what shape the returned list takes. Still, an agent can call it correctly with this information.

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

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

The schema already fully documents the single optional boolean parameter, so the baseline is 3. The description adds value by explaining when to set it ('when the agent needs proof...') and what it does ('probe each canonical vertical MCP and include current tool counts'), going beyond the schema's terse description.

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 action ('List all BrunoSan intelligence authorities') with a clear subject. However, it doesn't explicitly define what 'intelligence authorities' are, nor does it distinguish itself from sibling tools like inspect_domain or discover_brunosan beyond the word 'List'.

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 excellent guidance on default behavior ('instant and SSOT-only') and the condition for using the optional flag ('when the agent needs proof that the underlying MCP servers are reachable now'). It doesn't explicitly mention when not to use this tool or point to alternative tools, but the context is clear enough.

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?

With no annotations provided, the description carries the behavioral burden. It discloses that the plan is deterministic, names concrete live tools where possible, and that V1 plans and connects but does not proxy protected vertical calls. It does not cover auth, rate limits, or return format, so it stops short of a 5.

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 compact at four sentences and front-loads the core purpose. Each sentence adds a distinct constraint, though terms like 'LENS' and 'V1' are somewhat cryptic without additional context.

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 that there is no output schema and one parameter is undocumented, the description does not tell the agent what the returned plan/route looks like or what max_domains semantically affects. It covers purpose and a key limitation, but an agent would still be guessing about output shape and parameter impact.

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?

Only 'goal' has a schema description; 'max_domains' is entirely undocumented in the schema. The tool description adds little parameter-level meaning beyond rephrasing 'complex intelligence goal' and does not explain what max_domains controls or how it shapes the route.

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 opens with a specific verb–resource pair, 'Plan a source-authority route,' and clarifies the tool is for complex intelligence goals. It also distinguishes itself from sibling discovery/inspection tools by emphasizing that it names concrete live tools and does not proxy protected vertical calls.

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: use it for a 'complex intelligence goal' and when 'several specialized domains are useful,' it recommends LENS as the cross-domain layer. It also states a capability boundary, 'does not proxy protected vertical calls,' but does not explicitly name alternative sibling tools or when-not conditions.

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?

With no annotations, the description carries the behavioral burden and does meaningful work: it discloses that ranking is deterministic, that it operates over SSOT descriptions and live tool metadata, and that it returns candidates rather than domain names. It does not cover potential rate limits or auth expectations, but those are less critical for a search-style tool.

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 compact and front-loaded: the first sentence states the agent-facing purpose, and the following sentences add only high-value behavioral detail. No sentence is wasted.

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 is reasonably complete for a simple search tool, but with no output schema it only vaguely promises 'concrete tool candidates' without specifying the return shape, ranking scores, or how the limit parameter shapes results. It also does not advise on follow-up actions like inspecting a returned 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 coverage is 50%: the query parameter is described with examples, and the tool description reinforces that it accepts a natural-language goal. The limit parameter is not described in the tool description, though its default, minimum, and maximum in the schema make its behavior partly inferable.

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

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

The description states a specific verb and resource: 'Search the whole BrunoSan network for what an agent is trying to do.' It further distinguishes itself by saying it returns 'concrete tool candidates, not merely domain names,' which separates it from domain-listing siblings.

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

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

The description clearly implies use when an agent has a natural-language goal and needs capability routing, but it does not explicitly name alternatives such as inspect_tool, list_intelligence_domains, or plan_intelligence_route, nor does it state when not to use them.

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