Skip to main content
Glama

blackboard_set

Publish a belief to a shared blackboard. The stored belief includes timestamp and provenance, enabling multi-agent collaboration with traceable shared knowledge.

Instructions

Publish a belief to the shared blackboard.

Returns the stored belief as a dict (with timestamp + provenance).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYes
valueYes
sourceNomcp-client
confidenceNo
tagsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The @mcp.tool() decorated function 'blackboard_set' that handles the 'blackboard_set' tool. It accepts key, value, source, confidence, and tags, then upserts a Belief via the Blackboard instance and returns the stored belief as a dict.
    @mcp.tool()
    def blackboard_set(
        key: str,
        value: Any,
        source: str = "mcp-client",
        confidence: float = 0.7,
        tags: list[str] | None = None,
    ) -> dict[str, Any]:
        """Publish a belief to the shared blackboard.
    
        Returns the stored belief as a dict (with timestamp + provenance).
        """
        b = _BLACKBOARD.upsert(
            key=key,
            value=value,
            source=source,
            confidence=confidence,
            tags=tags,
        )
        logger.info("blackboard.set key=%s source=%s", key, source)
        return b.to_dict()
  • The @mcp.tool() decorator registers 'blackboard_set' as a FastMCP tool on line 33.
    @mcp.tool()
  • The Blackboard.upsert() method, called by blackboard_set, creates a new Belief dataclass instance and stores it keyed by key in the thread-safe _store dict.
    def upsert(
        self,
        key: str,
        value: Any,
        *,
        source: str,
        confidence: float = 0.7,
        ttl: Optional[float] = None,
        tags: Optional[list[str]] = None,
        provenance: Optional[dict[str, Any]] = None,
    ) -> Belief:
        with self._lock:
            b = Belief(
                key=key,
                value=value,
                source=source,
                confidence=confidence,
                ttl=ttl,
                tags=list(tags) if tags else [],
                provenance=dict(provenance) if provenance else {},
            )
            self._store[key] = b
            return b
  • The Belief dataclass used to represent a blackboard entry, with fields: key, value, source, confidence, ts, ttl, tags, provenance. The to_dict() method serializes it to a dict.
    @dataclass
    class Belief:
        key: str
        value: Any
        source: str
        confidence: float = 0.7
        ts: float = field(default_factory=time.time)
        ttl: Optional[float] = None
        tags: list[str] = field(default_factory=list)
        provenance: dict[str, Any] = field(default_factory=dict)
    
        def expired(self) -> bool:
            return self.ttl is not None and (time.time() - self.ts) > self.ttl
    
        def to_dict(self) -> dict[str, Any]:
            return self.__dict__.copy()
Behavior3/5

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

With no annotations, the description carries full burden for behavioral disclosure. It states that the tool returns a dict with timestamp and provenance, which is helpful. However, it does not explain side effects like overwriting existing keys, nor does it describe parameter behavior (e.g., confidence, tags) beyond the schema.

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

Conciseness5/5

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

The description consists of two concise sentences: the first clearly states the purpose, and the second describes the return value. There is no redundant or extraneous information.

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?

Given the tool's complexity (5 parameters, no schema descriptions, no annotations), the description is incomplete. It fails to explain parameter usage or the semantics of the belief storage, which is critical for correct invocation. The mention of the return dict is a minor plus but insufficient.

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

Parameters1/5

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

The input schema has 0% description coverage, and the tool description adds no explanations for the five parameters (key, value, source, confidence, tags). An agent has no semantic understanding of what these parameters mean or how to use them beyond the schema structure.

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

Purpose5/5

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

The description uses the specific verb 'publish' and the noun phrase 'belief to the shared blackboard', which clearly identifies the action and resource. It is easily distinguishable from sibling tools like blackboard_get (retrieve) and arithmetic tools.

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 is provided on when to use this tool versus alternatives such as blackboard_get or blackboard_query. The description only states what the tool does, without indicating prerequisites or appropriate contexts.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SiegKat/mcp-agent-blackboard'

If you have feedback or need assistance with the MCP directory API, please join our Discord server