Privacy-minimal capability discovery and bounded routing for Bursia agents (beta).
Scored across 8 tools
Each tool has a distinct focus, but the three preparation-oriented tools (agent_collaboration_request, human_bridge_request, prepare_outbound_invitation) could initially seem similar since none of them send anything. The policy/status tools are also somewhat related, though their descriptions clarify their separate purposes.
The naming is readable but not uniformly patterned: some tools use verb_noun style (discover_capabilities, prepare_outbound_invitation) while others are noun phrases or prefix-style names (bursia_status, capability_triage, human_oversight_policy). This mixing is not chaotic, but a consistent convention would improve predictability.
Eight tools is well-scoped for an agent-ecosystem server covering status, discovery, policies, triage, and request preparation. Each tool earns its place, and there is no obvious redundancy or bloat.
The tool surface covers the apparent domain well: public status, capability discovery, triage, oversight policy, gateway policy, and preparation of collaboration/human/outbound requests. The absence of actual sending/execution tools appears intentional for safety, though there is no capability detail or management endpoint, leaving a minor gap.
Prepare a privacy-minimal agent-to-agent collaboration request without contacting an external agent automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | ||
| protocols | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It discloses the non-automatic-contact behavior, which is a significant trait, but it omits other potential side effects, security or privacy details beyond the 'privacy-minimal' label, and what 'prepare' entails (e.g., validation, formatting, storing). The description is honest but not comprehensive.
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 with no fluff, front-loading the primary purpose and the key behavioral constraint. It is appropriately concise, though it sacrifices depth for brevity, which is a reasonable trade-off given the tool's simplicity.
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 no annotations, no output schema, and 0% schema description coverage, the description is minimal. It covers purpose and a behavioral trait but leaves parameter semantics, return behavior, and usage context (when vs. siblings) entirely unaddressed. An agent would likely need to consult additional documentation or guess.
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 0% description coverage for its two parameters ('request' and 'protocols'), and the tool description makes no mention of them. An agent must infer the meaning of 'request' and 'protocols' solely from the schema's type and requirement. This is a critical gap; the description fails to compensate for the schema's lack of documentation.
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 'prepare' and the resource 'agent-to-agent collaboration request', and adds the 'privacy-minimal' qualifier and the key constraint 'without contacting an external agent automatically'. This distinguishes it from siblings like prepare_outbound_invitation or outbound_gateway_policy, which likely involve actual contact or policy enforcement.
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 implicitly signals that this tool is a preparation step by noting it does not contact an external agent automatically, implying it should be used before any actual communication. However, it does not explicitly state when to prefer this over siblings like prepare_outbound_invitation or human_bridge_request, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return public Bursia operational status, discovery surfaces and oversight policy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It conveys that this is a public, input-free, read-style status operation, but it does not explain freshness, caching, error behavior, or whether the policy content overlaps with sibling policy tools.
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 focused sentence that front-loads the verb and primary outcome. It contains no filler or repetition, making it easy to scan.
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-input tool the description is mostly adequate, but there is no output schema and the return payload is only described with broad labels such as 'discovery surfaces' and 'oversight policy.' An agent may know the tool is callable but not the shape or semantics of the response.
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 zero parameters and is fully described by the empty properties object plus additionalProperties: false. Since there are no parameters, the description has no parameter-semantics burden, and the zero-parameter baseline of 4 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 uses a specific verb ('Return') and names the resource: public Bursia operational status, discovery surfaces, and oversight policy. It is clear at a high level but does not contrast itself with sibling tools such as human_oversight_policy or discover_capabilities, so it falls short of full differentiation.
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?
No guidance is given on when to use this tool versus its siblings. There are no usage conditions, exclusions, or references to related tools, so an agent must infer the appropriate context from the tool name and vague resource labels alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify a request into a public Bursia capability lane and return the next safe action.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It says 'classify' and 'return the next safe action' but does not explicitly state whether the operation is read-only, whether permissions are required, or what errors might occur. It also does not describe the output format.
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, concise sentence with no wasted words. It is front-loaded with the core action and outcome.
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 one parameter and no output schema, the description covers the basic purpose, but leaves key context undefined: what a 'capability lane' is, what constitutes a 'safe action', and what the return value looks like. It is minimally viable but not rich.
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 0%, so the description must compensate for the 'request' parameter. It clarifies that the parameter is the request to be classified, but does not provide format, examples, or constraints beyond the schema's minLength: 1. Minimal added value.
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 ('classify') and identifies the resource (a request into a capability lane) and the outcome (return the next safe action). It is clear enough to distinguish from sibling tools like discover_capabilities or bursia_status, though it does not name them explicitly.
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?
There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It implies the tool is for classifying a request, but does not state when not to use it or mention sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Bursia public capabilities and compatible entry points.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only states that it lists capabilities; it doesn't mention whether it performs network calls, has rate limits, or returns static data. It also doesn't explain what 'compatible entry points' means in terms of behavior. This is a significant gap for a discovery 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 extremely concise, just one sentence, with no fluff. It front-loads the action ('list') and resource. However, it is so brief that it sacrifices necessary detail, making it under-specified rather than concise.
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 tool's complexity is moderate (one optional parameter, no output schema), the description is inadequate. It doesn't describe the return format, the nature of 'capabilities', or the query parameter's use. An agent would need more context to know what information to provide or what to expect.
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 one parameter 'query' with no description, and schema coverage is 0%. The tool description doesn't explain what 'query' does or what format it should take. The description only says 'list', which doesn't imply a search. The tool name and description suggest discovery, but without explaining the query parameter, an agent cannot use it effectively.
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 purpose: listing Bursia public capabilities and compatible entry points. It uses a specific verb ('list') and resource ('Bursia public capabilities'), which is sufficiently clear. It doesn't explicitly differentiate from siblings, but the resource is unique enough that an agent can infer its role.
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 no guidance on when to use this tool versus alternatives. It doesn't mention conditions, exclusions, or relationships to siblings. An agent would have to guess when discovery is appropriate, especially compared to tools like capability_triage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare an authorized human-in-the-loop handoff request. No human is contacted automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | ||
| authorization | No |
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 does clearly state a key behavior: 'No human is contacted automatically,' which is valuable. However, it does not disclose other relevant details such as whether authorization is required to proceed, what side effects (if any) occur when the request is prepared, or reversibility. The single disclosed behavior is meaningful but insufficient for full 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 a single, front-loaded sentence with no filler. It combines the core purpose and a critical behavioral caveat efficiently. It loses one point because the extreme brevity leaves key dimensions (parameters, usage) unaddressed, but as a standalone sentence it is 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?
For a tool with 2 parameters, no output schema, and no annotations, the description is minimal. It does not explain the semantics of 'handoff request,' what 'authorized' entails, or what the parameters should contain. The key behavioral fact is noted, but an agent would still struggle to correctly formulate the request payload. This is inadequate for safe and 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 description coverage is 0%, and the description does not compensate by explaining either parameter. It never mentions 'request' or 'authorization' or their expected formats, purposes, or relationships. An agent has no clue what content to put in the required 'request' field or what 'authorization' should be, making this a significant gap.
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: 'Prepare an authorized human-in-the-loop handoff request.' It also adds a distinguishing negation, 'No human is contacted automatically,' which helps differentiate this from tools that might actually invoke human contact. However, it does not explicitly name sibling tools or contrast its scope with them, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It mentions 'authorized' and 'handoff request' but does not explain the conditions that should trigger use or when to choose a sibling such as human_oversight_policy or prepare_outbound_invitation. The only contextual hint is the negation about automatic human contact, which is a behavioral note rather than an explicit usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Bursia bounded-autonomy and human-supervision policy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior: it returns policy content and implies a read-only, side-effect-free call. With no annotations, it does not say whether the policy is the current version, whether access requires approval, or what the response format looks like, leaving a modest behavioral transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence containing only the essential action and target content. No filler, redundancy, or buried information; the verb is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only policy lookup, the description is largely complete: an agent knows the resource to return and that invocation is trivial. It would be slightly more complete if it named sibling policy tools as alternatives, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters and the schema already fully documents that. The description does not need to add parameter-level detail, so the zero-parameter baseline of 4 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 uses an explicit verb ('Return') and a specific resource ('Bursia bounded-autonomy and human-supervision policy'), so an agent knows this tool returns that particular policy. It does not explicitly compare itself to sibling tools such as outbound_gateway_policy, but the policy name is specific enough to make the distinction inferable.
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?
No guidance is given about when to use this tool versus a sibling tool such as outbound_gateway_policy or human_bridge_request. Intended triggers, prerequisites, and exclusions are left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Bursia Beacon outbound discovery policy. External sends require target allowlisting and explicit human approval.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. The verb 'Return' indicates a read-only informational operation, and the description adds meaningful domain context: external sends require target allowlisting and explicit human approval. This gives the agent concrete expectations beyond the tool name.
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 short sentences with no filler. The first sentence states the core action and resource, and the second adds a key policy rule. 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 parameterless policy-retrieval tool with no output schema, the description is largely complete: it states what is returned and highlights the most important policy constraint. It does not specify the exact return format, but this is minor for such a simple 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?
The tool has zero parameters, so the baseline is 4. There is no parameter detail to add, and the description appropriately focuses on the tool's purpose and policy content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and the specific resource ('Bursia Beacon outbound discovery policy'). It distinguishes itself from siblings like human_oversight_policy by naming a distinct policy scope, though it does not explicitly contrast itself with that sibling.
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 the tool is used to retrieve outbound discovery policy, and the policy content suggests it applies when checking external-send requirements. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare, but do not send, a Bursia invitation candidate for a documented machine endpoint or opt-in recipient.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| message | Yes | ||
| permissionBasis | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose one key behavior: the tool does not send the invitation and only prepares a candidate. It stops short of saying whether the candidate is persisted, returned, or subject to permission checks, which leaves behavioral transparency only partially satisfied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence contains no filler and immediately communicates the send/no-send distinction. This is appropriately sized for the information it conveys.
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 three-required-parameter tool with no annotations, no output schema, and no property descriptions, the description is insufficient: message is unspecified, target format is unspecified, and the tool's behavior after preparation is unstated. An agent could not reliably populate all required fields.
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 property descriptions are 0%, so the description must supply meaning for target, message, and permissionBasis. It only implicitly covers target/permissionBasis via 'documented machine endpoint or opt-in recipient'; it says nothing about what message should contain, so the agent still lacks needed semantics.
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 names a specific action ('prepare, but do not send'), a concrete resource ('Bursia invitation candidate'), and a target boundary ('documented machine endpoint or opt-in recipient'). It reads clearly, but it does not explicitly contrast any sibling tool, so an agent must infer how it differs from send/policy 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 phrase 'but do not send' implies this tool is for staging an invitation rather than transmitting it, and the recipient phrase gives a selection criterion. However, there is no explicit when-to-use/when-not-to-use statement or mention of alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
agent_collaboration_requesthuman_bridge_requesthuman_oversight_policyoutbound_gateway_policyprepare_outbound_invitationbursia_statuscapability_triagediscover_capabilitiesVerified agent routing with bounded discovery, outcome evidence and economic policy.
Outcome-first agent fallback: free discovery, minimal routing, declared costs, verified execution.
Discover willing agents, request permission, hand off durable tasks, and recover private results.
Verifiable agent DIDs + capability discovery — the passport & directory of the A2A economy.
Add one secure layer between your agents and this server.