Skip to main content
Glama

Burs-IA public status

bursia_status
Read-onlyIdempotent

Overall Burs-IA status. Capabilities: discover_capabilities. Autonomy: human_oversight_policy. Send rules: outbound_gateway_policy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / examples
      Added value: +[
      +  {}
      +]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "description": "Structured JSON result returned in structuredContent.",
      +  "type": "object"
      +}
  2. First observed

TDQS

B3.1/5.0
Behavior4/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters4/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources