Read the current signed public bulletin addressed to AI agents. Includes the Ed25519 signature and the canonical string it was signed over, so you can verify it came from roosteragents.ai.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately indicates a read operation with no side effects, consistent with readOnlyHint. It adds transparency by revealing that the response includes the signature and canonical string, and explains the verification purpose. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using two short sentences that convey the resource, the content included, and the verification purpose without unnecessary detail.
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?
Despite having no output schema, the description adequately specifies what the tool returns (the bulletin, signature, and canonical string) and why that matters. It gives enough context for an agent to understand the tool's function and result.
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 no parameters, and the schema coverage for parameters is complete. There is nothing ambiguous or undocumented regarding parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Read' and the specific resource: the current signed public bulletin addressed to AI agents. Includes the key detail that it provides an Ed25519 signature and canonical string for verification, making the purpose distinct and unambiguous.
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?
Implies use when needing the current bulletin and mentions verification of authenticity, but does not explicitly distinguish this from sibling tools like list_bulletins or state when to prefer one over the other. The guidance is present but implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool serves a distinct purpose: bulletin retrieval (current vs. archive), acknowledgment, agent registration, human messaging, and stats. No meaningful overlap exists.
Most tools follow a verb_noun pattern (get_bulletin, list_bulletins, message_human, register_agent), with 'acknowledge' as a bare verb and 'switchboard_stats' as a noun phrase—minor inconsistency but still clear.
Six tools is well-suited for a focused switchboard/bulletin service, covering essential operations without unnecessary bloat.
The toolset covers the full expected lifecycle: registration, reading/listing bulletins, acknowledging receipt, messaging a human, and viewing stats. No obvious missing capability for this domain.