Burs-IA
Server Details
Burs-IA public MCP entry point for capability discovery, bounded routing and interoperability.
- Status
- Healthy
- Uptime
- 99.9% over 41 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 12 tools
The tools form related clusters (status/policy, discovery/routing, collaboration/approval, WORKNET) with subtle boundaries that rely on cross-references to distinguish. For example, discover_capabilities, capability_triage, and bursia_verify_mcp overlap in routing/browsing, and bursia_status, human_oversight_policy, and outbound_gateway_policy are all policy/status tools that could be confused without careful reading.
All names use snake_case and are descriptive, but the convention is mixed: some tools carry a bursia_ prefix while others do not, and verb styles vary (e.g., discover_capabilities vs bursia_status vs human_oversight_policy). This is readable but not predictable.
12 tools fit the broad scope of an agent coordination platform, covering status, policies, discovery, verification, WORKNET tasks, and collaboration. The set is slightly heavy on meta/policy tools, but each covers a distinct facet and the count stays within a reasonable range.
The surface covers discovery, status, policies, MCP verification, WORKNET listing/reading/preparation, collaboration/approval, and outbound invitation preparation. Direct apply, claim, send, or payment operations are intentionally absent and gated by human approval, so the safe preparatory lifecycle is largely complete.
Available Tools
12 toolsagent_collaboration_requestPrepare agent collaborationBRead-onlyIdempotentInspect
Agent collaboration. Known target: prepare_outbound_invitation. Human approval: human_bridge_request. No external contact.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Public, non-sensitive collaboration need. | |
| protocols | No | Preferred public interoperability protocols. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The only extra behavioral signal is "No external contact," which merely reinforces openWorldHint=false, so the description adds little beyond structured data. No auth, rate, or side-effect detail is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loads the topic, which is good, but it is composed of telegraphic fragments rather than well-formed sentences, leaving meaning ambiguous. Brevity here shades into under-specification rather than clean conciseness.
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?
An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a coordination/routing tool with ambiguous purpose, the description leaves the agent without enough to confidently choose it over the eleven siblings, so it is only adequately 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 schema already documents both parameters (request as a public non-sensitive need, protocols as preferred interoperability protocols). The description adds nothing about parameter meaning or constraints, 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?
"Agent collaboration" restates the name/title rather than naming a concrete verb+resource, so the core purpose stays vague. The "Known target: prepare_outbound_invitation" line gives a directional hint about what it leads to, but an agent still cannot tell precisely what this tool itself does beyond routing.
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 points to a downstream target (prepare_outbound_invitation) and an approval path (human_bridge_request), which is partial when-to-use guidance. It does not clarify when NOT to use this versus siblings like capability_triage or discover_capabilities, so the routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bursia_statusBurs-IA public statusBRead-onlyIdempotentInspect
Overall Burs-IA status. Capabilities: discover_capabilities. Autonomy: human_oversight_policy. Send rules: outbound_gateway_policy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, non-destructive, idempotent, closed-world). The description adds that this is an aggregate of named capabilities and policies, giving real context beyond the annotations about what the status encompasses.
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?
Brief and front-loaded, but the labeled fragments ('Capabilities:', 'Autonomy:', 'Send rules:') are terse to the point of ambiguity. The labels imply an enumeration but the meaning of each entry is unclear.
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 status/aggregate tool with an output schema, the description should say what the response covers and how it relates to the sibling names it mentions. As written, an agent cannot tell whether the named items are returned values, references, or something else.
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?
Zero parameters, so baseline 4 applies. The description correctly notes no inputs are needed by simply not listing any.
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?
States 'Overall Burs-IA status' — a clear resource but a vague purpose. It never specifies what 'status' actually returns or what question it answers. It also doesn't differentiate from siblings like discover_capabilities, which it references.
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 on when to call this tool vs alternatives. It lists discover_capabilities, human_oversight_policy, and outbound_gateway_policy as 'capabilities'/'rules' but never says whether this tool aggregates them or whether the agent should call those tools directly instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bursia_verify_mcpVerify a public MCP endpointARead-onlyIdempotentInspect
Known MCP endpoint: get a read-only verification report. To browse Burs-IA first, use discover_capabilities. No target tool runs; no credentials; not a security certification.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | Public HTTPS MCP Streamable HTTP endpoint. Port 443 only; private, local, reserved and mixed public/private DNS targets are rejected. | |
| idempotencyKey | No | Optional caller key. Exact replay returns the cached receipt for five minutes; conflicting reuse is rejected. | |
| protocolVersion | No | MCP protocol version used for the bounded read-only verification probe. 2026-07-28 uses server/discover + tools/list; legacy revisions use initialize + tools/list. | 2025-11-25 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: no target tool is executed, no credentials are needed, and the result is explicitly not a security certification.
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 compact clauses, front-loaded with the action and immediately followed by the routing rule. Every sentence earns its place; only the clipped 'Known MCP endpoint:' opening costs it the top score.
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, return values need no explanation, and the annotations carry the safety profile. The description rounds out the picture with scope limits and routing, leaving little missing for a 3-parameter, 1-required 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 endpoint, idempotencyKey and protocolVersion are already fully documented in the schema, including replay semantics and protocol-version behavior. The description adds no parameter-level detail beyond what the schema provides, so the 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 states a specific action and resource: retrieve a read-only verification report for a known MCP endpoint, and it explicitly distinguishes itself from the sibling discover_capabilities. The telegraphic 'Known MCP endpoint:' fragment is slightly clipped, so it falls short of the crispest 5, but an agent can confidently separate this from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear selection rule: use this when the endpoint is already known, and use discover_capabilities to browse Burs-IA first. That names the alternative explicitly, though it does not spell out when-not conditions beyond that one routing hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bursia_worknet_paid_tasksFind paid Burs-IA workARead-onlyIdempotentInspect
Use this in ChatGPT to list paid opportunities already registered by WORKNET. Returns public-safe opportunity metadata only; it does not apply, claim work, accept terms, spend money or contact anyone.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum opportunities to return. | |
| query | No | Optional skill, technology, source, title or WORKNET id filter. | |
| source | No | Optional source filter such as GITHUB, UPWORK or bounty source. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds meaningful context: 'public-safe opportunity metadata only' and that it does not spend money or contact anyone. It stops short of return format or rate-limit details, but those are less critical given the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and then the key behavioral constraints. Every phrase earns its place with no 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 all parameters fully documented, the description covers purpose, usage context, and behavioral boundaries adequately. Nothing critical is missing 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 description coverage is 100%, and all three parameters have clear descriptions. The description adds no parameter-specific syntax, defaults, or formatting beyond what the schema already provides, 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 states a specific verb and resource: 'list paid opportunities already registered by WORKNET.' It also clarifies what it does not do, distinguishing it from write/apply siblings like prepare_mission. An agent knows exactly what this tool returns without opening the schema.
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 says 'Use this in ChatGPT to list paid opportunities,' giving clear usage context, and explicitly excludes actions like applying or claiming work. However, it does not name the specific alternative tools for those excluded actions, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bursia_worknet_prepare_missionPrepare a paid mission safelyARead-onlyIdempotentInspect
Create a deterministic internal pre-contract mission preview for one paid WORKNET item. This performs no external write, claim, application, acceptance, payment or contact; any binding action remains gated by exact human approval and BURSIA TRUST.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Canonical paid WORKNET id. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description nonetheless adds real value by enumerating the exact side-effect boundary (no write, claim, application, acceptance, payment or contact) and flagging that binding action is gated by human approval and BURSIA TRUST.
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 the action, followed by the binding-constraint caveat. No filler sentences; the enumerated list of non-actions earns its space.
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?
An output schema exists, so return values need not be explained. The description covers purpose, side-effect boundary, and the approval gate; only explicit alternative-tool routing is absent, which is a minor gap for this complexity level.
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 single id parameter is fully documented with pattern and description, so the baseline of 3 applies. The description's phrase 'one paid WORKNET item' reinforces the parameter's intent but adds no syntax or format detail 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 states a specific verb+resource: 'Create a deterministic internal pre-contract mission preview for one paid WORKNET item.' The word 'preview' and 'pre-contract' cleanly separate it from siblings like bursia_worknet_task and bursia_worknet_paid_tasks, even without naming them.
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 (run this before committing to a paid WORKNET item to obtain a non-binding preview) but no explicit when/when-not or named alternative appears. The negative scope (no write/claim/payment) helps an agent infer boundaries but does not route to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bursia_worknet_taskInspect one paid WORKNET taskARead-onlyIdempotentInspect
Read the public-safe canonical record for one paid WORKNET opportunity before deciding whether to prepare internal work.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Canonical WORKNET id, for example WN-043. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds meaningful context beyond them by labeling the output a 'public-safe canonical record', signaling the data is sanitized rather than internal detail.
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 tight sentence with no wasted words, and the retrieval purpose is front-loaded. It is efficient, though it packs the usage rationale into the same clause rather than separating concerns.
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, return values need not be explained, and the single fully-documented parameter needs no extra description. The description supplies sufficient context for a read-only single-record lookup, though it could name the sibling it precedes.
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%; the id parameter has a pattern, length bounds, and example already documented in the schema. The description adds no additional syntax or format guidance, so the baseline 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?
States a specific verb (Read) and resource (public-safe canonical record for one paid WORKNET opportunity), which is clear. It implies single-item retrieval versus the plural sibling bursia_worknet_paid_tasks, but never names that sibling, so differentiation is only implicit.
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 'before deciding whether to prepare internal work' gives implied usage context, tying it loosely to the prepare_mission workflow. However, no alternatives are named and no explicit when-not guidance is provided, leaving the agent to infer when this beats the paid_tasks list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
capability_triageTriage a capability requestBRead-onlyIdempotentInspect
Route a bounded need. Browse: discover_capabilities. Known MCP endpoint: bursia_verify_mcp. Does not execute the external action.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Public, non-sensitive request to classify. |
Output Schema
| Name | Required | Description |
|---|---|---|
| lane | Yes | |
| next | Yes | |
| canonical | Yes | |
| oversight | Yes | |
| valueFirst | Yes | |
| entryAlgorithm | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful boundary — "Does not execute the external action" — which sets expectations that calling it will not accomplish the underlying task. Beyond that one sentence there is no additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loads the purpose, which is good, but the telegraphic noun-phrase fragments ("Browse: ...", "Known MCP endpoint: ...") read as terse notes rather than complete sentences, and the brevity comes at the cost of clarity rather than from eliminating 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?
An output schema exists, so return values need not be described, and annotations plus full schema coverage lighten the burden. Still, for a routing/decision tool the description never explains what a triage outcome means or how to interpret the classification, leaving a meaningful gap for the agent.
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?
With a single parameter and 100% schema description coverage ("Public, non-sensitive request to classify"), the schema already carries parameter meaning. The description adds nothing about the request string — not what form a well-formed request takes, nor the non-sensitive constraint — so it stays at the baseline.
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?
"Route a bounded need" gestures at the tool's function but never states plainly that it classifies/triages a request, and "bounded need" is undefined jargon. It does name two sibling tools as onward destinations, which helps differentiate it from discover_capabilities and bursia_verify_mcp, but the core verb+resource remains fuzzy.
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 two routing fragments ("Browse: discover_capabilities", "Known MCP endpoint: bursia_verify_mcp") imply when to skip this tool in favor of siblings, which is real guidance. However, there is no explicit statement of when to call capability_triage itself, what makes a need "bounded," or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_capabilitiesDiscover Burs-IA capabilitiesARead-onlyIdempotentInspect
Browse public Burs-IA capabilities and guidance. To visit, explore https://burs-ia.com/start or https://burs-ia.com/city; no message, registration or purchase is required. For optional ONDA encrypted-message pilot documentation, query 'encrypted messaging'; this does not send a message or certify identity. For a known public MCP endpoint use bursia_verify_mcp; for a bounded public need use capability_triage. Never include secrets in discovery queries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional public capability need to filter or contextualize discovery. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value on top: it clarifies the tool sends no message and certifies no identity, requires no registration or purchase, and warns against including secrets. Minor omission: no statement of what the discovery result actually contains, though that is likely covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose in one sentence, then layers routing, optional pilot docs, and a safety constraint. Nearly every clause carries information, though the phrasing "To visit, explore ..." is slightly awkward and the URLs sit apart from the browsing verb.
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-required-parameter, read-only discovery tool with full schema coverage, annotations, and an output schema, the description covers purpose, alternatives, and safety. Nothing essential is missing for correct invocation; only the nature of returned results is left entirely to the output 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 coverage is 100% and the single optional query parameter is documented there, so baseline 3 applies; the description goes further by demonstrating concrete query content ('encrypted messaging'). No syntax or filtering semantics beyond that example, so not a 5.
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?
States a specific verb and resource ("Browse public Burs-IA capabilities and guidance") and explicitly contrasts itself with two named siblings, bursia_verify_mcp for known endpoints and capability_triage for bounded needs. An agent can position this tool among the eleven siblings without opening any schema.
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?
Gives explicit routing rules: use bursia_verify_mcp for a known public MCP endpoint, capability_triage for a bounded public need, and query 'encrypted messaging' for ONDA pilot docs. It also states prerequisites are absent ("no message, registration or purchase is required"), which is the when-not condition an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
human_bridge_requestPrepare human handoffBRead-onlyIdempotentInspect
Human approval/review. Agent peer: agent_collaboration_request. Known target: prepare_outbound_invitation. No contact/write.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Public, non-sensitive handoff need. | |
| authorization | No | Optional human authorization reference; this field does not itself grant authority. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, non-destructive, idempotent, and non-open-world behavior. The description adds only 'No contact/write,' which is consistent but largely redundant with those hints, and it does not discuss authorization, rate limits, or other operational context.
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 very short and front-loads the main purpose and routing clues. It is efficient, though its fragmentary phrasing slightly reduces clarity.
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?
Annotations and schema descriptions cover safety and parameters, and an output schema exists. The description still leaves usage conditions implicit, making it only adequately complete for an agent deciding when and how to call this 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 both parameters are fully documented in the schema itself. The description adds no parameter-level meaning beyond what the structured fields already provide.
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 'Human approval/review' and names sibling relationships, but it lacks a specific verb-resource phrase such as 'request human review of a bounded result.' An agent can infer the purpose, but it is not crisply stated.
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 routes the agent by naming 'agent_collaboration_request' as the agent peer and 'prepare_outbound_invitation' as a known target, and it excludes contact/write. However, it does not explicitly say when this tool should be chosen over those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
human_oversight_policyRead human oversight policyBRead-onlyIdempotentInspect
General autonomy policy. Send rules: outbound_gateway_policy. Overall status: bursia_status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is fully covered by structured data. The description adds no behavioral context at all - no indication of what the policy contains, how large it is, or when it must be consulted - so it contributes nothing 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?
It is very short with no redundancy, which is a plus, but it is written as three telegraphic noun fragments rather than sentences, so the structure is ambiguous and the most useful routing information is buried in the trailing clauses.
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?
An output schema exists and there are no parameters, so the description does not need to cover return values or inputs. What remains missing is why or when an agent should pull this policy, which is the one piece of context a terse policy-reader tool needs; the sibling pointers partially compensate.
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 takes zero parameters, so per the rubric the baseline is 4. There is no parameter semantics for the description to clarify, and schema coverage is 100%.
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 the resource ('General autonomy policy') but uses a verbless fragment, so it never states the action (reading/retrieving the policy) even though the title does. The two follow-on fragments do carve out sibling domains, so the agent can roughly place the tool, but the core purpose statement is 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?
It explicitly routes two adjacent concerns to named alternatives ('Send rules: outbound_gateway_policy', 'Overall status: bursia_status'), which maps topics to tools and implies what this tool is for. It stops short of an explicit when-to-use/when-not statement for this tool itself, so it does not reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
outbound_gateway_policyRead outbound gateway policyARead-onlyIdempotentInspect
Outbound send rules. General autonomy: human_oversight_policy. Prepare: prepare_outbound_invitation. Sends require human approval.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds a meaningful behavioral fact beyond those annotations: 'Sends require human approval,' which clarifies the human-in-the-loop requirement governing outbound sending.
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 the core resource and then gives two routing pointers plus an approval requirement in four short fragments. Every sentence earns its place, with no filler or 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?
For a simple read-only policy tool with no parameters and an output schema, the description covers the key routing and approval context. It could be slightly more complete by explicitly stating that it returns the outbound gateway policy rules, but the title and output schema fill that gap.
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 object schema, so there is no parameter semantics to explain. Per the rubric, a zero-parameter tool receives a baseline of 4 when the schema requires no additional 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 opens with the noun phrase 'Outbound send rules,' which identifies the resource but does not state a verb such as 'read' or 'return.' It does distinguish related siblings by naming human_oversight_policy and prepare_outbound_invitation, but the core action remains implied rather than explicit.
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 gives clear routing guidance: 'General autonomy: human_oversight_policy' and 'Prepare: prepare_outbound_invitation,' which tells the agent which sibling to use for related needs. It also states the approval condition for sends, though it does not explicitly say 'use this tool when you need outbound send rules.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prepare_outbound_invitationPrepare outbound invitationAInspect
Known target: prepare a local invitation. No target: agent_collaboration_request. Human review: human_bridge_request. It does not send.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | HTTPS target URL. Private/local targets are rejected. | |
| agentId | No | Optional public-safe agent identifier. When supplied it is bound into the exact action digest. | |
| message | Yes | Public-safe invitation text; no secrets or personal data. | |
| permissionBasis | Yes | Documented basis for preparing the candidate. | |
| operatorOrganizationIdentifier | No | Optional public-safe operator/organization identifier; do not send personal data. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-read-only, non-destructive, non-idempotent, closed-world, but say nothing about transmission. The sentence 'It does not send' adds a materially important behavioral fact beyond the annotations, though it omits side effects, the rejection of private/local targets, and any auth expectations.
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?
Roughly twenty words with no padding, and the routing facts are front-loaded. The fragmentary colon-clause style is compact but slightly cryptic, keeping it short of ideal clarity.
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, full parameter descriptions, and annotations present, the description only needs to add routing and non-sending semantics, which it does. A note on why permissionBasis must be documented or what 'prepare' yields would have closed the remaining gap.
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 all five parameters are already documented, including the enum for permissionBasis and the digest-binding behavior of agentId. The description adds no parameter-level meaning, so the 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 names a specific action (prepare) and output (a local invitation), and separates itself from siblings by routing 'known target' cases here. However, 'local invitation' is left unexplained and the phrasing is telegraphic, so the agent gets the verb and resource but not a plain statement of what the tool produces.
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 gives explicit selection conditions against two named alternatives: no target routes to agent_collaboration_request, human review routes to human_bridge_request. That is genuine when-to-use guidance, though no prerequisites (e.g. permissionBasis requirements) or when-not-to-use cases are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
capability_triage6 fields changed- added
Output schema / $defsAdded value: +{ + "route": { + "additionalProperties": false, + "if": { + "properties": { + "status": { + "const": "AWAITING_HUMAN_AUTHORIZATION" + } + }, + "required": [ + "status" + ] + }, + "properties": { + "admissionRequired": { + "const": false + }, + "afterEvidence": { + "type": "string" + }, + "automaticExternalContact": { + "const": false + }, + "automaticHumanContact": { + "const": false + }, + "contributionPath": { + "items": { + "type": "string" + }, + "maxItems": 8, + "minItems": 8, + "type": "array" + }, + "executed": { + "const": false, + "type": "boolean" + }, + "externalBindingRequiresHumanApproval": { + "const": true + }, + "externalWriteRequiresRepositoryRules": { + "const": true + }, + "firstValueSurface": { + "type": "string" + }, + "firstValueTool": { + "enum": [ + "bursia_verify_mcp", + "bursia_worknet_paid_tasks", + "capability_triage" + ], + "type": "string" + }, + "humanApprovalRequired": { + "const": true, + "type": "boolean" + }, + "mode": { + "enum": [ + "trust", + "worknet", + "value-first", + "open-contribution", + "reception", + "human-in-the-loop", + "agent-to-agent", + "station" + ], + "type": "string" + }, + "nextSurface": { + "type": "string" + }, + "permissions": { + "type": "string" + }, + "policy": { + "const": "https://burs-ia.com/.well-known/human-oversight.json", + "type": "string" + }, + "prepareTool": { + "const": "bursia_worknet_prepare_mission" + }, + "publicRepository": { + "type": "string" + }, + "recurringMonitorClaimed": { + "const": false + }, + "requirement": { + "type": "string" + }, + "sensitiveActionsRequireHumanApproval": { + "const": true + }, + "status": { + "enum": [ + "proposal_route_ready", + "remediation_candidate_ready", + "baseline_ready", + "ready", + "diagnosis_ready", + "paid_work_discovery_ready", + "contributor_route_ready", + "optional_entry_ready", + "awaiting_authorized_connector", + "match_request_ready", + "resume_ready", + "AWAITING_HUMAN_AUTHORIZATION" + ], + "type": "string" + }, + "verifyFirstRecommended": { + "const": true + }, + "workSurface": { + "type": "string" + } + }, + "required": [ + "mode", + "status", + "requirement" + ], + "then": { + "required": [ + "executed", + "humanApprovalRequired", + "policy" + ] + }, + "type": "object" + } +} - added
Output schema / additionalPropertiesAdded value: +false - added
Output schema / anyOfAdded value: +[ + { + "properties": { + "lane": { + "enum": [ + "governed_action", + "visitor_entry" + ] + }, + "next": { + "allOf": [ + { + "$ref": "#/$defs/route" + }, + { + "properties": {}, + "required": [ + "firstValueSurface", + "admissionRequired" + ] + } + ] + } + } + }, + { + "properties": { + "lane": { + "enum": [ + "remediation" + ] + }, + "next": { + "allOf": [ + { + "$ref": "#/$defs/route" + }, + { + "properties": { + "firstValueTool": { + "const": "bursia_verify_mcp" + } + }, + "required": [ + "verifyFirstRecommended", + "firstValueTool", + "nextSurface", + "admissionRequired" + ] + } + ] + } + } + }, + { + "properties": { + "lane": { + "enum": [ + "monitoring" + ] + }, + "next": { + "allOf": [ + { + "$ref": "#/$defs/route" + }, + { + "properties": { + "firstValueTool": { + "const": "bursia_verify_mcp" + } + }, + "required": [ + "firstValueTool", + "recurringMonitorClaimed", + "admissionRequired" + ] + } + ] + } + } + }, + { + "properties": { + "lane": { + "enum": [ + "verification" + ] + }, + "next": { + "allOf": [ + { + "$ref": "#/$defs/route" + }, + { + "properties": { + "firstValueTool": { + "const": "bursia_verify_mcp" + } + }, + "required": [ + "firstValueTool", + "admissionRequired" + ] + } + ] + } + } + }, + { + "properties": { + "lane": { + "enum": [ + "problem_diagnosis" + ] + }, + "next": { + "allOf": [ + { + "$ref": "#/$defs/route" + }, + { + "properties": { + "firstValueTool": { + "const": "bursia_verify_mcp" + } + }, + "required": [ + "firstValueTool", + "afterEvidence", + "admissionRequired" + ] + } + ] + } + } + }, + { + "properties": { + "lane": { + "enum": [ + "work_exchange" + ] + }, + "next": { + "allOf": [ + { + "$ref": "#/$defs/route" + }, + { + "properties": { + "firstValueTool": { + "const": "bursia_worknet_paid_tasks" + } + }, + "required": [ + "firstValueTool", + "prepareTool", + "externalBindingRequiresHumanApproval", + "admissionRequired" + ] + } + ] + } + } + }, + { + "properties": { + "lane": { + "enum": [ + "contributor" + ] + }, + "next": { + "allOf": [ + { + "$ref": "#/$defs/route" + }, + { + "properties": { + "firstValueTool": { + "const": "capability_triage" + } + }, + "required": [ + "publicRepository", + "firstValueTool", + "workSurface", + "contributionPath", + "permissions", + "externalWriteRequiresRepositoryRules", + "sensitiveActionsRequireHumanApproval", + "admissionRequired" + ] + } + ] + } + } + }, + { + "properties": { + "lane": { + "enum": [ + "human_bridge" + ] + }, + "next": { + "allOf": [ + { + "$ref": "#/$defs/route" + }, + { + "properties": {}, + "required": [ + "automaticHumanContact" + ] + } + ] + } + } + }, + { + "properties": { + "lane": { + "enum": [ + "collaboration" + ] + }, + "next": { + "allOf": [ + { + "$ref": "#/$defs/route" + }, + { + "properties": {}, + "required": [ + "automaticExternalContact" + ] + } + ] + } + } + }, + { + "properties": { + "lane": { + "enum": [ + "continuity", + "cost_optimization", + "discovery", + "routing", + "general" + ] + }, + "next": { + "allOf": [ + { + "$ref": "#/$defs/route" + }, + { + "properties": {}, + "required": [] + } + ] + } + } + }, + { + "properties": { + "lane": { + "const": "encrypted_messaging_documentation" + }, + "next": { + "additionalProperties": false, + "properties": { + "admissionRequired": { + "const": false + }, + "arbitraryRecipientSupported": { + "const": false + }, + "automaticSend": { + "const": false + }, + "availability": { + "type": "string" + }, + "availableViaMcpSendingTool": { + "const": false + }, + "clientExampleUrl": { + "type": "string" + }, + "conditions": { + "type": "string" + }, + "description": { + "type": "string" + }, + "documentationUrl": { + "type": "string" + }, + "exampleConsent": { + "additionalProperties": false, + "properties": { + "command": { + "type": "string" + }, + "description": { + "type": "string" + }, + "requiresOwnPermission": { + "const": true + } + }, + "required": [ + "command", + "requiresOwnPermission", + "description" + ], + "type": "object" + }, + "exampleRuntime": { + "additionalProperties": false, + "properties": { + "minMajor": { + "type": "number" + }, + "name": { + "type": "string" + }, + "requiresLocalExecution": { + "const": true + } + }, + "required": [ + "name", + "minMajor", + "requiresLocalExecution" + ], + "type": "object" + }, + "executed": { + "const": false + }, + "identityCertification": { + "const": false + }, + "kind": { + "const": "DOCUMENTATION_ONLY" + }, + "limits": { + "additionalProperties": false, + "properties": { + "maxOriginalMessagesTotal": { + "type": "number" + }, + "maxPerKey": { + "type": "number" + }, + "remainingQuota": { + "type": "string" + } + }, + "required": [ + "maxOriginalMessagesTotal", + "maxPerKey", + "remainingQuota" + ], + "type": "object" + }, + "nextAction": { + "additionalProperties": false, + "properties": { + "method": { + "const": "GET" + }, + "url": { + "type": "string" + } + }, + "required": [ + "method", + "url" + ], + "type": "object" + }, + "optional": { + "const": true + }, + "privacy": { + "type": "string" + }, + "recipientId": { + "type": "string" + }, + "requiresSenderConsent": { + "const": true + }, + "status": { + "const": "DOCUMENTATION_ONLY" + }, + "visitorPrice": { + "type": "string" + }, + "window": { + "additionalProperties": false, + "properties": { + "closesAt": { + "type": "string" + }, + "startsAt": { + "type": "string" + } + }, + "required": [ + "startsAt", + "closesAt" + ], + "type": "object" + }, + "withoutLocalExecution": { + "additionalProperties": false, + "properties": { + "explanation": { + "type": "string" + }, + "handoffPerformed": { + "const": false + }, + "status": { + "const": "GUIDANCE_ONLY" + } + }, + "required": [ + "status", + "handoffPerformed", + "explanation" + ], + "type": "object" + } + }, + "required": [ + "kind", + "executed", + "optional", + "requiresSenderConsent", + "availableViaMcpSendingTool", + "exampleRuntime", + "exampleConsent", + "withoutLocalExecution", + "availability", + "recipientId", + "arbitraryRecipientSupported", + "description", + "nextAction", + "documentationUrl", + "clientExampleUrl", + "visitorPrice", + "identityCertification", + "automaticSend", + "window", + "limits", + "privacy", + "conditions", + "status", + "admissionRequired" + ], + "type": "object" + } + } + } +] - removed
Output schema / descriptionRemoved value: -"Structured JSON result returned in structuredContent." - added
Output schema / propertiesAdded value: +{ + "canonical": { + "const": "https://burs-ia.com", + "type": "string" + }, + "entryAlgorithm": { + "const": "BURSIA_VALUE_FIRST_AGENT_ENTRY_V1", + "type": "string" + }, + "lane": { + "enum": [ + "governed_action", + "remediation", + "monitoring", + "verification", + "problem_diagnosis", + "work_exchange", + "contributor", + "visitor_entry", + "human_bridge", + "collaboration", + "continuity", + "cost_optimization", + "discovery", + "routing", + "general", + "encrypted_messaging_documentation" + ], + "type": "string" + }, + "next": { + "type": "object" + }, + "oversight": { + "additionalProperties": false, + "properties": { + "auditability": { + "const": true + }, + "autonomyModel": { + "type": "string" + }, + "externalSideEffectsRequireExplicitAuthorization": { + "const": true + }, + "humanIdentityRequiredForBasicDiscovery": { + "const": false + }, + "humanSupervisionRequired": { + "const": true + }, + "policyUrl": { + "type": "string" + }, + "privacyByDesign": { + "const": true + }, + "revocationSupported": { + "const": true + } + }, + "required": [ + "humanSupervisionRequired", + "autonomyModel", + "externalSideEffectsRequireExplicitAuthorization", + "humanIdentityRequiredForBasicDiscovery", + "privacyByDesign", + "auditability", + "revocationSupported", + "policyUrl" + ], + "type": "object" + }, + "valueFirst": { + "const": true, + "type": "boolean" + } +} - added
Output schema / requiredAdded value: +[ + "lane", + "valueFirst", + "entryAlgorithm", + "next", + "oversight", + "canonical" +]
- Changed
discover_capabilities2 fields changed- added
Output schema / anyOfAdded value: +[ + { + "additionalProperties": false, + "properties": { + "capabilities": { + "items": { + "enum": [ + "value-first-agent-entry", + "problem-diagnosis-routing", + "evidence-to-remediation-routing", + "monitor-baseline-routing", + "governed-action-routing", + "mcp-public-verification", + "capability-discovery", + "agent-collaboration", + "human-in-the-loop-request", + "human-supervised-autonomy", + "session-continuity", + "interoperability-routing", + "controlled-outbound-discovery", + "visitor-lounge", + "super-host-conversation", + "chatgpt-work-exchange", + "worknet-paid-work-discovery", + "worknet-paid-mission-preparation", + "open-agent-contribution" + ], + "type": "string" + }, + "maxItems": 19, + "minItems": 19, + "type": "array" + }, + "confidentiality": { + "type": "string" + }, + "entryAlgorithm": { + "additionalProperties": false, + "properties": { + "goal": { + "type": "string" + }, + "noAccountRequiredFor": { + "items": { + "type": "string" + }, + "maxItems": 4, + "minItems": 4, + "type": "array" + }, + "principle": { + "type": "string" + }, + "routes": { + "items": { + "additionalProperties": false, + "properties": { + "admissionRequired": { + "const": false + }, + "automaticExternalContact": { + "const": false + }, + "externalBindingRequiresHumanApproval": { + "const": true + }, + "firstValueSurface": { + "type": "string" + }, + "firstValueTool": { + "anyOf": [ + { + "const": "bursia_verify_mcp" + }, + { + "const": "capability_triage" + }, + { + "const": "bursia_worknet_paid_tasks" + }, + { + "const": "agent_collaboration_request" + } + ] + }, + "humanApprovalRequiredForExecution": { + "const": true + }, + "intent": { + "type": "string" + }, + "nextSurface": { + "type": "string" + }, + "optionalAdmission": { + "const": true + }, + "recurringMonitorClaimed": { + "const": false + } + }, + "required": [ + "intent" + ], + "type": "object" + }, + "maxItems": 8, + "minItems": 8, + "type": "array" + }, + "schema": { + "const": "BURSIA_VALUE_FIRST_AGENT_ENTRY_V1" + }, + "supportedPublicProtocols": { + "items": { + "type": "string" + }, + "maxItems": 3, + "minItems": 3, + "type": "array" + }, + "truthBoundary": { + "type": "string" + } + }, + "required": [ + "schema", + "principle", + "goal", + "supportedPublicProtocols", + "noAccountRequiredFor", + "routes", + "truthBoundary" + ], + "type": "object" + }, + "interfaces": { + "additionalProperties": false, + "properties": { + "a2a": { + "type": "string" + }, + "agentCard": { + "type": "string" + }, + "mcp": { + "type": "string" + }, + "outboundPolicy": { + "type": "string" + }, + "reception": { + "type": "string" + }, + "visitorHost": { + "type": "string" + }, + "visitorLounge": { + "type": "string" + }, + "visitorMcp": { + "type": "string" + }, + "workExchange": { + "additionalProperties": false, + "properties": { + "inspectTask": { + "const": "bursia_worknet_task" + }, + "listPaid": { + "const": "bursia_worknet_paid_tasks" + }, + "prepareMission": { + "const": "bursia_worknet_prepare_mission" + } + }, + "required": [ + "listPaid", + "inspectTask", + "prepareMission" + ], + "type": "object" + } + }, + "required": [ + "a2a", + "agentCard", + "reception", + "mcp", + "visitorLounge", + "visitorMcp", + "visitorHost", + "outboundPolicy", + "workExchange" + ], + "type": "object" + }, + "ondaDocumentation": { + "additionalProperties": false, + "properties": { + "arbitraryRecipientSupported": { + "const": false + }, + "automaticSend": { + "const": false + }, + "availability": { + "type": "string" + }, + "availableViaMcpSendingTool": { + "const": false + }, + "clientExampleUrl": { + "type": "string" + }, + "conditions": { + "type": "string" + }, + "description": { + "type": "string" + }, + "documentationUrl": { + "type": "string" + }, + "exampleConsent": { + "additionalProperties": false, + "properties": { + "command": { + "type": "string" + }, + "description": { + "type": "string" + }, + "requiresOwnPermission": { + "const": true + } + }, + "required": [ + "command", + "requiresOwnPermission", + "description" + ], + "type": "object" + }, + "exampleRuntime": { + "additionalProperties": false, + "properties": { + "minMajor": { + "type": "number" + }, + "name": { + "type": "string" + }, + "requiresLocalExecution": { + "const": true + } + }, + "required": [ + "name", + "minMajor", + "requiresLocalExecution" + ], + "type": "object" + }, + "executed": { + "const": false + }, + "identityCertification": { + "const": false + }, + "kind": { + "const": "DOCUMENTATION_ONLY" + }, + "limits": { + "additionalProperties": false, + "properties": { + "maxOriginalMessagesTotal": { + "type": "number" + }, + "maxPerKey": { + "type": "number" + }, + "remainingQuota": { + "type": "string" + } + }, + "required": [ + "maxOriginalMessagesTotal", + "maxPerKey", + "remainingQuota" + ], + "type": "object" + }, + "nextAction": { + "additionalProperties": false, + "properties": { + "method": { + "const": "GET" + }, + "url": { + "type": "string" + } + }, + "required": [ + "method", + "url" + ], + "type": "object" + }, + "optional": { + "const": true + }, + "privacy": { + "type": "string" + }, + "recipientId": { + "type": "string" + }, + "requiresSenderConsent": { + "const": true + }, + "visitorPrice": { + "type": "string" + }, + "window": { + "additionalProperties": false, + "properties": { + "closesAt": { + "type": "string" + }, + "startsAt": { + "type": "string" + } + }, + "required": [ + "startsAt", + "closesAt" + ], + "type": "object" + }, + "withoutLocalExecution": { + "additionalProperties": false, + "properties": { + "explanation": { + "type": "string" + }, + "handoffPerformed": { + "const": false + }, + "status": { + "const": "GUIDANCE_ONLY" + } + }, + "required": [ + "status", + "handoffPerformed", + "explanation" + ], + "type": "object" + } + }, + "required": [ + "kind", + "executed", + "optional", + "requiresSenderConsent", + "availableViaMcpSendingTool", + "exampleRuntime", + "exampleConsent", + "withoutLocalExecution", + "availability", + "recipientId", + "arbitraryRecipientSupported", + "description", + "nextAction", + "documentationUrl", + "clientExampleUrl", + "visitorPrice", + "identityCertification", + "automaticSend", + "window", + "limits", + "privacy", + "conditions" + ], + "type": "object" + } + }, + "required": [ + "entryAlgorithm", + "capabilities", + "interfaces", + "confidentiality" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "capabilities": { + "items": { + "enum": [ + "mcp-public-verification", + "chatgpt-work-exchange", + "worknet-paid-work-discovery", + "worknet-paid-mission-preparation", + "agent-collaboration", + "human-supervised-autonomy", + "human-in-the-loop-request", + "problem-diagnosis-routing", + "evidence-to-remediation-routing", + "monitor-baseline-routing", + "value-first-agent-entry", + "visitor-lounge", + "super-host-conversation", + "governed-action-routing", + "session-continuity", + "interoperability-routing", + "open-agent-contribution", + "controlled-outbound-discovery", + "capability-discovery" + ], + "type": "string" + }, + "maxItems": 19, + "type": "array", + "uniqueItems": true + }, + "executed": { + "const": false, + "type": "boolean" + }, + "guidance": { + "minLength": 1, + "type": "string" + }, + "humanApprovalRequired": { + "type": "boolean" + }, + "matchStatus": { + "enum": [ + "MATCH", + "MULTIPLE_MATCHES", + "NO_MATCH" + ], + "type": "string" + }, + "nextTool": { + "enum": [ + "bursia_verify_mcp", + "bursia_worknet_paid_tasks", + "agent_collaboration_request", + "human_oversight_policy", + "capability_triage", + "outbound_gateway_policy" + ], + "type": "string" + } + }, + "required": [ + "matchStatus", + "capabilities", + "nextTool", + "guidance", + "executed", + "humanApprovalRequired" + ], + "type": "object" + } +] - removed
Output schema / descriptionRemoved value: -"Structured JSON result returned in structuredContent."
1 tool update
- Changed
bursia_verify_mcp4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -false - added
Output schema / anyOfAdded value: +[ + { + "additionalProperties": false, + "properties": { + "compatibility": { + "additionalProperties": false, + "properties": { + "authenticatedTarget": { + "type": "boolean" + }, + "initializedNotification": { + "type": "boolean" + }, + "mcpInitialize": { + "type": "boolean" + }, + "schemaQuality": { + "enum": [ + "PASS", + "PARTIAL", + "FAIL", + "UNKNOWN" + ], + "type": "string" + }, + "serverDiscover": { + "type": "boolean" + }, + "toolsList": { + "type": "boolean" + } + }, + "required": [ + "mcpInitialize", + "initializedNotification", + "serverDiscover", + "toolsList", + "schemaQuality", + "authenticatedTarget" + ], + "type": "object" + }, + "coreMutation": { + "const": false + }, + "endpoint": { + "format": "uri", + "maxLength": 2048, + "minLength": 12, + "type": "string" + }, + "errors": { + "items": { + "additionalProperties": false, + "properties": { + "code": { + "enum": [ + "DEPENDENCY_TIMEOUT", + "DEPENDENCY_TOTAL_TIMEOUT", + "DEPENDENCY_CANCELLED", + "DEPENDENCY_NETWORK_ERROR", + "DEPENDENCY_RESPONSE_TOO_LARGE", + "DEPENDENCY_HTTP_ERROR", + "DEPENDENCY_PROTOCOL_ERROR" + ], + "type": "string" + }, + "phase": { + "enum": [ + "INITIALIZE", + "DISCOVERY" + ], + "type": "string" + } + }, + "required": [ + "code", + "phase" + ], + "type": "object" + }, + "maxItems": 10, + "type": "array" + }, + "evidenceHash": { + "maxLength": 64, + "minLength": 64, + "type": "string" + }, + "evidenceReceipt": { + "additionalProperties": false, + "properties": { + "certification": { + "const": false + }, + "evidenceHash": { + "maxLength": 64, + "minLength": 64, + "type": "string" + }, + "evidenceId": { + "maxLength": 160, + "minLength": 1, + "type": "string" + }, + "humanApprovalBasis": { + "maxLength": 256, + "minLength": 1, + "type": "string" + }, + "humanApprovalRequired": { + "const": false + }, + "observedAt": { + "format": "date-time", + "type": "string" + }, + "persistedByVerifier": { + "const": false + }, + "receiptType": { + "const": "BURSIA_PUBLIC_MCP_VERIFICATION_RECEIPT_V1", + "type": "string" + }, + "sideEffect": { + "const": "BOUNDED_PUBLIC_READ_ONLY_MCP_PROBE", + "type": "string" + }, + "taskId": { + "maxLength": 128, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "receiptType", + "taskId", + "evidenceId", + "evidenceHash", + "observedAt", + "sideEffect", + "humanApprovalRequired", + "humanApprovalBasis", + "persistedByVerifier", + "certification" + ], + "type": "object" + }, + "latencyMs": { + "additionalProperties": false, + "properties": { + "initializeMs": { + "anyOf": [ + { + "minimum": 0, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "toolsListMs": { + "anyOf": [ + { + "minimum": 0, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "totalMs": { + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "initializeMs", + "toolsListMs", + "totalMs" + ], + "type": "object" + }, + "limitations": { + "items": { + "maxLength": 500, + "minLength": 1, + "type": "string" + }, + "maxItems": 10, + "type": "array" + }, + "metering": { + "additionalProperties": false, + "properties": { + "capability": { + "const": "BURSIA_VERIFY_MCP_PUBLIC", + "type": "string" + }, + "computeCost": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "enum": [ + "UNKNOWN" + ], + "type": "string" + } + ] + }, + "estimatedTotalCost": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "enum": [ + "UNKNOWN" + ], + "type": "string" + } + ] + }, + "evidenceId": { + "maxLength": 160, + "minLength": 1, + "type": "string" + }, + "executionTime": { + "minimum": 0, + "type": "integer" + }, + "executionTimeMs": { + "minimum": 0, + "type": "integer" + }, + "externalApiCost": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "enum": [ + "UNKNOWN" + ], + "type": "string" + } + ] + }, + "externalHttpCalls": { + "minimum": 0, + "type": "integer" + }, + "modelCalls": { + "minimum": 0, + "type": "integer" + }, + "retryCount": { + "minimum": 0, + "type": "integer" + }, + "reviewCost": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "enum": [ + "UNKNOWN" + ], + "type": "string" + } + ] + }, + "taskId": { + "maxLength": 128, + "minLength": 1, + "type": "string" + }, + "tokensIn": { + "minimum": 0, + "type": "integer" + }, + "tokensOut": { + "minimum": 0, + "type": "integer" + }, + "toolCalls": { + "minimum": 0, + "type": "integer" + }, + "toolVersion": { + "const": "0.8.0", + "type": "string" + } + }, + "required": [ + "taskId", + "capability", + "executionTime", + "executionTimeMs", + "toolVersion", + "modelCalls", + "tokensIn", + "tokensOut", + "toolCalls", + "externalHttpCalls", + "externalApiCost", + "computeCost", + "retryCount", + "reviewCost", + "estimatedTotalCost", + "evidenceId" + ], + "type": "object" + }, + "observedAt": { + "format": "date-time", + "type": "string" + }, + "protocolVersion": { + "maxLength": 64, + "minLength": 1, + "type": "string" + }, + "publicSafeOnly": { + "const": true + }, + "replayed": { + "type": "boolean" + }, + "schema": { + "const": "BURSIA_VERIFY_MCP_RESULT_V1", + "type": "string" + }, + "schemaIssues": { + "items": { + "additionalProperties": false, + "properties": { + "code": { + "maxLength": 128, + "minLength": 1, + "type": "string" + }, + "message": { + "maxLength": 500, + "minLength": 1, + "type": "string" + }, + "path": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "severity": { + "enum": [ + "ERROR", + "WARN" + ], + "type": "string" + }, + "tool": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "severity", + "code", + "tool", + "path", + "message" + ], + "type": "object" + }, + "maxItems": 100, + "type": "array" + }, + "status": { + "enum": [ + "PASS", + "PARTIAL", + "FAIL" + ], + "type": "string" + }, + "toolNames": { + "items": { + "maxLength": 256, + "minLength": 1, + "type": "string" + }, + "maxItems": 100, + "type": "array" + }, + "toolsDiscovered": { + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "schema", + "status", + "endpoint", + "protocolVersion", + "toolsDiscovered", + "toolNames", + "schemaIssues", + "compatibility", + "latencyMs", + "errors", + "limitations", + "observedAt", + "metering", + "coreMutation", + "publicSafeOnly", + "evidenceHash", + "evidenceReceipt", + "replayed" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "code": { + "maxLength": 128, + "minLength": 1, + "type": "string" + }, + "reason": { + "maxLength": 256, + "minLength": 1, + "type": "string" + }, + "retryAfterMs": { + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "code" + ], + "type": "object" + } +] - removed
Output schema / propertiesRemoved value: -{ - "compatibility": { - "additionalProperties": false, - "properties": { - "authenticatedTarget": { - "type": "boolean" - }, - "initializedNotification": { - "type": "boolean" - }, - "mcpInitialize": { - "type": "boolean" - }, - "schemaQuality": { - "enum": [ - "PASS", - "PARTIAL", - "FAIL", - "UNKNOWN" - ], - "type": "string" - }, - "serverDiscover": { - "type": "boolean" - }, - "toolsList": { - "type": "boolean" - } - }, - "required": [ - "mcpInitialize", - "initializedNotification", - "serverDiscover", - "toolsList", - "schemaQuality", - "authenticatedTarget" - ], - "type": "object" - }, - "coreMutation": { - "const": false - }, - "endpoint": { - "format": "uri", - "maxLength": 2048, - "minLength": 12, - "type": "string" - }, - "errors": { - "items": { - "additionalProperties": false, - "properties": { - "code": { - "enum": [ - "DEPENDENCY_TIMEOUT", - "DEPENDENCY_TOTAL_TIMEOUT", - "DEPENDENCY_CANCELLED", - "DEPENDENCY_NETWORK_ERROR", - "DEPENDENCY_RESPONSE_TOO_LARGE", - "DEPENDENCY_HTTP_ERROR", - "DEPENDENCY_PROTOCOL_ERROR" - ], - "type": "string" - }, - "phase": { - "enum": [ - "INITIALIZE", - "DISCOVERY" - ], - "type": "string" - } - }, - "required": [ - "code", - "phase" - ], - "type": "object" - }, - "maxItems": 10, - "type": "array" - }, - "evidenceHash": { - "maxLength": 64, - "minLength": 64, - "type": "string" - }, - "evidenceReceipt": { - "additionalProperties": false, - "properties": { - "certification": { - "const": false - }, - "evidenceHash": { - "maxLength": 64, - "minLength": 64, - "type": "string" - }, - "evidenceId": { - "maxLength": 160, - "minLength": 1, - "type": "string" - }, - "humanApprovalBasis": { - "maxLength": 256, - "minLength": 1, - "type": "string" - }, - "humanApprovalRequired": { - "const": false - }, - "observedAt": { - "format": "date-time", - "type": "string" - }, - "persistedByVerifier": { - "const": false - }, - "receiptType": { - "const": "BURSIA_PUBLIC_MCP_VERIFICATION_RECEIPT_V1", - "type": "string" - }, - "sideEffect": { - "const": "BOUNDED_PUBLIC_READ_ONLY_MCP_PROBE", - "type": "string" - }, - "taskId": { - "maxLength": 128, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "receiptType", - "taskId", - "evidenceId", - "evidenceHash", - "observedAt", - "sideEffect", - "humanApprovalRequired", - "humanApprovalBasis", - "persistedByVerifier", - "certification" - ], - "type": "object" - }, - "latencyMs": { - "additionalProperties": false, - "properties": { - "initializeMs": { - "anyOf": [ - { - "minimum": 0, - "type": "integer" - }, - { - "type": "null" - } - ] - }, - "toolsListMs": { - "anyOf": [ - { - "minimum": 0, - "type": "integer" - }, - { - "type": "null" - } - ] - }, - "totalMs": { - "minimum": 0, - "type": "integer" - } - }, - "required": [ - "initializeMs", - "toolsListMs", - "totalMs" - ], - "type": "object" - }, - "limitations": { - "items": { - "maxLength": 500, - "minLength": 1, - "type": "string" - }, - "maxItems": 10, - "type": "array" - }, - "metering": { - "additionalProperties": false, - "properties": { - "capability": { - "const": "BURSIA_VERIFY_MCP_PUBLIC", - "type": "string" - }, - "computeCost": { - "anyOf": [ - { - "minimum": 0, - "type": "number" - }, - { - "enum": [ - "UNKNOWN" - ], - "type": "string" - } - ] - }, - "estimatedTotalCost": { - "anyOf": [ - { - "minimum": 0, - "type": "number" - }, - { - "enum": [ - "UNKNOWN" - ], - "type": "string" - } - ] - }, - "evidenceId": { - "maxLength": 160, - "minLength": 1, - "type": "string" - }, - "executionTime": { - "minimum": 0, - "type": "integer" - }, - "executionTimeMs": { - "minimum": 0, - "type": "integer" - }, - "externalApiCost": { - "anyOf": [ - { - "minimum": 0, - "type": "number" - }, - { - "enum": [ - "UNKNOWN" - ], - "type": "string" - } - ] - }, - "externalHttpCalls": { - "minimum": 0, - "type": "integer" - }, - "modelCalls": { - "minimum": 0, - "type": "integer" - }, - "retryCount": { - "minimum": 0, - "type": "integer" - }, - "reviewCost": { - "anyOf": [ - { - "minimum": 0, - "type": "number" - }, - { - "enum": [ - "UNKNOWN" - ], - "type": "string" - } - ] - }, - "taskId": { - "maxLength": 128, - "minLength": 1, - "type": "string" - }, - "tokensIn": { - "minimum": 0, - "type": "integer" - }, - "tokensOut": { - "minimum": 0, - "type": "integer" - }, - "toolCalls": { - "minimum": 0, - "type": "integer" - }, - "toolVersion": { - "const": "0.8.0", - "type": "string" - } - }, - "required": [ - "taskId", - "capability", - "executionTime", - "executionTimeMs", - "toolVersion", - "modelCalls", - "tokensIn", - "tokensOut", - "toolCalls", - "externalHttpCalls", - "externalApiCost", - "computeCost", - "retryCount", - "reviewCost", - "estimatedTotalCost", - "evidenceId" - ], - "type": "object" - }, - "observedAt": { - "format": "date-time", - "type": "string" - }, - "protocolVersion": { - "maxLength": 64, - "minLength": 1, - "type": "string" - }, - "publicSafeOnly": { - "const": true - }, - "replayed": { - "type": "boolean" - }, - "schema": { - "const": "BURSIA_VERIFY_MCP_RESULT_V1", - "type": "string" - }, - "schemaIssues": { - "items": { - "additionalProperties": false, - "properties": { - "code": { - "maxLength": 128, - "minLength": 1, - "type": "string" - }, - "message": { - "maxLength": 500, - "minLength": 1, - "type": "string" - }, - "path": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "severity": { - "enum": [ - "ERROR", - "WARN" - ], - "type": "string" - }, - "tool": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "severity", - "code", - "tool", - "path", - "message" - ], - "type": "object" - }, - "maxItems": 100, - "type": "array" - }, - "status": { - "enum": [ - "PASS", - "PARTIAL", - "FAIL" - ], - "type": "string" - }, - "toolNames": { - "items": { - "maxLength": 256, - "minLength": 1, - "type": "string" - }, - "maxItems": 100, - "type": "array" - }, - "toolsDiscovered": { - "minimum": 0, - "type": "integer" - } -} - removed
Output schema / requiredRemoved value: -[ - "schema", - "status", - "endpoint", - "protocolVersion", - "toolsDiscovered", - "toolNames", - "schemaIssues", - "compatibility", - "latencyMs", - "errors", - "limitations", - "observedAt", - "metering", - "coreMutation", - "publicSafeOnly", - "evidenceHash", - "evidenceReceipt", - "replayed" -]
1 tool update
- Changed
bursia_verify_mcp4 fields changed- changed
Input schema / properties / protocolVersion / descriptionPrevious value: -"MCP protocol version used for the bounded initialize/list probe."New value: +"MCP protocol version used for the bounded read-only verification probe. 2026-07-28 uses server/discover + tools/list; legacy revisions use initialize + tools/list." - changed
Input schema / properties / protocolVersion / enumPrevious value: -[ - "2025-11-25", - "2025-06-18" -]New value: +[ + "2026-07-28", + "2025-11-25", + "2025-06-18" +] - added
Output schema / properties / compatibility / properties / serverDiscoverAdded value: +{ + "type": "boolean" +} - changed
Output schema / properties / compatibility / requiredPrevious value: -[ - "mcpInitialize", - "initializedNotification", - "toolsList", - "schemaQuality", - "authenticatedTarget" -]New value: +[ + "mcpInitialize", + "initializedNotification", + "serverDiscover", + "toolsList", + "schemaQuality", + "authenticatedTarget" +]
5 tool updates
- Changed
bursia_verify_mcp1 field changed- changed
Output schema / properties / metering / properties / toolVersion / constPrevious value: -"0.7.1"New value: +"0.8.0"
- Added
bursia_worknet_paid_tasks - Added
bursia_worknet_prepare_mission - Added
bursia_worknet_task - Changed
prepare_outbound_invitation3 fields changed- changed
Input schema / examplesPrevious value: -[ - { - "message": "Public interoperability invitation.", - "permissionBasis": "public_machine_endpoint", - "target": "https://example.org/a2a" - } -]New value: +[ + { + "agentId": "agent-example-01", + "message": "Public interoperability invitation.", + "permissionBasis": "public_machine_endpoint", + "target": "https://example.org/a2a" + } +] - added
Input schema / properties / agentIdAdded value: +{ + "description": "Optional public-safe agent identifier. When supplied it is bound into the exact action digest.", + "maxLength": 128, + "minLength": 1, + "pattern": "^[A-Za-z0-9][A-Za-z0-9._:-]{0,127}$", + "type": "string" +} - added
Input schema / properties / operatorOrganizationIdentifierAdded value: +{ + "description": "Optional public-safe operator/organization identifier; do not send personal data.", + "maxLength": 128, + "minLength": 1, + "pattern": "^[A-Za-z0-9][A-Za-z0-9._:-]{0,127}$", + "type": "string" +}
1 tool update
- Changed
bursia_verify_mcp32 fields changed- added
Output schema / properties / compatibility / additionalPropertiesAdded value: +false - added
Output schema / properties / compatibility / propertiesAdded value: +{ + "authenticatedTarget": { + "type": "boolean" + }, + "initializedNotification": { + "type": "boolean" + }, + "mcpInitialize": { + "type": "boolean" + }, + "schemaQuality": { + "enum": [ + "PASS", + "PARTIAL", + "FAIL", + "UNKNOWN" + ], + "type": "string" + }, + "toolsList": { + "type": "boolean" + } +} - added
Output schema / properties / compatibility / requiredAdded value: +[ + "mcpInitialize", + "initializedNotification", + "toolsList", + "schemaQuality", + "authenticatedTarget" +] - added
Output schema / properties / endpoint / formatAdded value: +"uri" - added
Output schema / properties / endpoint / maxLengthAdded value: +2048 - added
Output schema / properties / endpoint / minLengthAdded value: +12 - added
Output schema / properties / errors / items / additionalPropertiesAdded value: +false - added
Output schema / properties / errors / items / propertiesAdded value: +{ + "code": { + "enum": [ + "DEPENDENCY_TIMEOUT", + "DEPENDENCY_TOTAL_TIMEOUT", + "DEPENDENCY_CANCELLED", + "DEPENDENCY_NETWORK_ERROR", + "DEPENDENCY_RESPONSE_TOO_LARGE", + "DEPENDENCY_HTTP_ERROR", + "DEPENDENCY_PROTOCOL_ERROR" + ], + "type": "string" + }, + "phase": { + "enum": [ + "INITIALIZE", + "DISCOVERY" + ], + "type": "string" + } +} - added
Output schema / properties / errors / items / requiredAdded value: +[ + "code", + "phase" +] - added
Output schema / properties / errors / maxItemsAdded value: +10 - added
Output schema / properties / evidenceReceipt / additionalPropertiesAdded value: +false - added
Output schema / properties / evidenceReceipt / propertiesAdded value: +{ + "certification": { + "const": false + }, + "evidenceHash": { + "maxLength": 64, + "minLength": 64, + "type": "string" + }, + "evidenceId": { + "maxLength": 160, + "minLength": 1, + "type": "string" + }, + "humanApprovalBasis": { + "maxLength": 256, + "minLength": 1, + "type": "string" + }, + "humanApprovalRequired": { + "const": false + }, + "observedAt": { + "format": "date-time", + "type": "string" + }, + "persistedByVerifier": { + "const": false + }, + "receiptType": { + "const": "BURSIA_PUBLIC_MCP_VERIFICATION_RECEIPT_V1", + "type": "string" + }, + "sideEffect": { + "const": "BOUNDED_PUBLIC_READ_ONLY_MCP_PROBE", + "type": "string" + }, + "taskId": { + "maxLength": 128, + "minLength": 1, + "type": "string" + } +} - added
Output schema / properties / evidenceReceipt / requiredAdded value: +[ + "receiptType", + "taskId", + "evidenceId", + "evidenceHash", + "observedAt", + "sideEffect", + "humanApprovalRequired", + "humanApprovalBasis", + "persistedByVerifier", + "certification" +] - added
Output schema / properties / latencyMs / additionalPropertiesAdded value: +false - added
Output schema / properties / latencyMs / propertiesAdded value: +{ + "initializeMs": { + "anyOf": [ + { + "minimum": 0, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "toolsListMs": { + "anyOf": [ + { + "minimum": 0, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "totalMs": { + "minimum": 0, + "type": "integer" + } +} - added
Output schema / properties / latencyMs / requiredAdded value: +[ + "initializeMs", + "toolsListMs", + "totalMs" +] - added
Output schema / properties / limitations / items / maxLengthAdded value: +500 - added
Output schema / properties / limitations / items / minLengthAdded value: +1 - added
Output schema / properties / limitations / maxItemsAdded value: +10 - added
Output schema / properties / metering / additionalPropertiesAdded value: +false - added
Output schema / properties / metering / propertiesAdded value: +{ + "capability": { + "const": "BURSIA_VERIFY_MCP_PUBLIC", + "type": "string" + }, + "computeCost": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "enum": [ + "UNKNOWN" + ], + "type": "string" + } + ] + }, + "estimatedTotalCost": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "enum": [ + "UNKNOWN" + ], + "type": "string" + } + ] + }, + "evidenceId": { + "maxLength": 160, + "minLength": 1, + "type": "string" + }, + "executionTime": { + "minimum": 0, + "type": "integer" + }, + "executionTimeMs": { + "minimum": 0, + "type": "integer" + }, + "externalApiCost": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "enum": [ + "UNKNOWN" + ], + "type": "string" + } + ] + }, + "externalHttpCalls": { + "minimum": 0, + "type": "integer" + }, + "modelCalls": { + "minimum": 0, + "type": "integer" + }, + "retryCount": { + "minimum": 0, + "type": "integer" + }, + "reviewCost": { + "anyOf": [ + { + "minimum": 0, + "type": "number" + }, + { + "enum": [ + "UNKNOWN" + ], + "type": "string" + } + ] + }, + "taskId": { + "maxLength": 128, + "minLength": 1, + "type": "string" + }, + "tokensIn": { + "minimum": 0, + "type": "integer" + }, + "tokensOut": { + "minimum": 0, + "type": "integer" + }, + "toolCalls": { + "minimum": 0, + "type": "integer" + }, + "toolVersion": { + "const": "0.7.1", + "type": "string" + } +} - added
Output schema / properties / metering / requiredAdded value: +[ + "taskId", + "capability", + "executionTime", + "executionTimeMs", + "toolVersion", + "modelCalls", + "tokensIn", + "tokensOut", + "toolCalls", + "externalHttpCalls", + "externalApiCost", + "computeCost", + "retryCount", + "reviewCost", + "estimatedTotalCost", + "evidenceId" +] - added
Output schema / properties / protocolVersion / maxLengthAdded value: +64 - added
Output schema / properties / protocolVersion / minLengthAdded value: +1 - added
Output schema / properties / schema / constAdded value: +"BURSIA_VERIFY_MCP_RESULT_V1" - added
Output schema / properties / schemaIssues / items / additionalPropertiesAdded value: +false - added
Output schema / properties / schemaIssues / items / propertiesAdded value: +{ + "code": { + "maxLength": 128, + "minLength": 1, + "type": "string" + }, + "message": { + "maxLength": 500, + "minLength": 1, + "type": "string" + }, + "path": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "severity": { + "enum": [ + "ERROR", + "WARN" + ], + "type": "string" + }, + "tool": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } +} - added
Output schema / properties / schemaIssues / items / requiredAdded value: +[ + "severity", + "code", + "tool", + "path", + "message" +] - added
Output schema / properties / schemaIssues / maxItemsAdded value: +100 - added
Output schema / properties / toolNames / items / maxLengthAdded value: +256 - added
Output schema / properties / toolNames / items / minLengthAdded value: +1 - added
Output schema / properties / toolNames / maxItemsAdded value: +100
9 tool updates
- Changed
agent_collaboration_request9 fields changed- added
Input schema / examplesAdded value: +[ + { + "protocols": [ + "MCP" + ], + "request": "Compare MCP tool contracts." + } +] - added
Input schema / properties / protocols / descriptionAdded value: +"Preferred public interoperability protocols." - added
Input schema / properties / protocols / items / maxLengthAdded value: +64 - added
Input schema / properties / protocols / items / minLengthAdded value: +1 - added
Input schema / properties / protocols / maxItemsAdded value: +8 - added
Input schema / properties / protocols / uniqueItemsAdded value: +true - added
Input schema / properties / request / descriptionAdded value: +"Public, non-sensitive collaboration need." - added
Input schema / properties / request / maxLengthAdded value: +2000 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "Structured JSON result returned in structuredContent.", + "type": "object" +}
- Changed
bursia_status2 fields changed- added
Input schema / examplesAdded value: +[ + {} +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "Structured JSON result returned in structuredContent.", + "type": "object" +}
- Added
bursia_verify_mcp - Changed
capability_triage4 fields changed- added
Input schema / examplesAdded value: +[ + { + "request": "Verify whether this MCP endpoint exposes bounded tool schemas." + } +] - added
Input schema / properties / request / descriptionAdded value: +"Public, non-sensitive request to classify." - added
Input schema / properties / request / maxLengthAdded value: +2000 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "Structured JSON result returned in structuredContent.", + "type": "object" +}
- Changed
discover_capabilities5 fields changed- added
Input schema / examplesAdded value: +[ + { + "query": "verify a public MCP server" + } +] - added
Input schema / properties / query / descriptionAdded value: +"Optional public capability need to filter or contextualize discovery." - added
Input schema / properties / query / maxLengthAdded value: +500 - added
Input schema / properties / query / minLengthAdded value: +1 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "Structured JSON result returned in structuredContent.", + "type": "object" +}
- Changed
human_bridge_request7 fields changed- added
Input schema / examplesAdded value: +[ + { + "request": "Escalate this bounded technical result for human review." + } +] - added
Input schema / properties / authorization / descriptionAdded value: +"Optional human authorization reference; this field does not itself grant authority." - added
Input schema / properties / authorization / maxLengthAdded value: +500 - added
Input schema / properties / authorization / minLengthAdded value: +1 - added
Input schema / properties / request / descriptionAdded value: +"Public, non-sensitive handoff need." - added
Input schema / properties / request / maxLengthAdded value: +2000 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "Structured JSON result returned in structuredContent.", + "type": "object" +}
- Changed
human_oversight_policy2 fields changed- added
Input schema / examplesAdded value: +[ + {} +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "Structured JSON result returned in structuredContent.", + "type": "object" +}
- Changed
outbound_gateway_policy2 fields changed- added
Input schema / examplesAdded value: +[ + {} +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "Structured JSON result returned in structuredContent.", + "type": "object" +}
- Changed
prepare_outbound_invitation10 fields changed- added
Input schema / examplesAdded value: +[ + { + "message": "Public interoperability invitation.", + "permissionBasis": "public_machine_endpoint", + "target": "https://example.org/a2a" + } +] - added
Input schema / properties / message / descriptionAdded value: +"Public-safe invitation text; no secrets or personal data." - added
Input schema / properties / message / maxLengthAdded value: +1500 - added
Input schema / properties / message / minLengthAdded value: +1 - added
Input schema / properties / permissionBasis / descriptionAdded value: +"Documented basis for preparing the candidate." - added
Input schema / properties / target / descriptionAdded value: +"HTTPS target URL. Private/local targets are rejected." - added
Input schema / properties / target / formatAdded value: +"uri" - added
Input schema / properties / target / maxLengthAdded value: +2048 - added
Input schema / properties / target / minLengthAdded value: +9 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "Structured JSON result returned in structuredContent.", + "type": "object" +}
5 tool updates
- Added
agent_collaboration_request - Added
human_bridge_request - Added
human_oversight_policy - Added
outbound_gateway_policy - Added
prepare_outbound_invitation
3 tool updates
- First observed
bursia_status - First observed
capability_triage - First observed
discover_capabilities
Related MCP Connectors
Public MCP for agent verification, work discovery and governed interoperability.
AgencyAI's public MCP for service discovery and AI-readiness assessment.
MCP delegation fallback for AI agents to discover capabilities, knowledge, tools, and collaborators.
Single entry point for the GOSCE portfolio: routes orchestrators to verified agents by capability, w
Related MCP Servers
- AlicenseAqualityAmaintenanceEnables AI harnesses to connect to a single MCP endpoint that routes to multiple downstream MCP servers, discovering and executing capabilities on demand while keeping tool schemas out of context.413 npmApache 2.0
- AlicenseNot gradedqualityBmaintenanceEnables MCP clients to access upstream MCP capabilities and OpenAI-compatible model routes through one invariant-preserving, policy-bounded endpoint with deterministic routing, leases, durable Tasks/Runs, and verifiable outcomes.Apache 2.0
- AlicenseNot gradedqualityDmaintenanceMCP server for agent-to-agent communication -- capability discovery, task delegation, and result aggregation across MCP agents.14 npm1MIT
- AlicenseNot gradedqualityCmaintenanceExposes runtime-local capabilities from browsers, apps, devices, and local processes to AI agents through a unified MCP bridge, enabling path-based discovery and invocation of live context.10MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.