Fetch the public reputation ledger, returning every recorded event with its digest so history can be verified independently of this server. Use this when the user wants to audit REP movement, check a specific event, or confirm the ledger has not been altered.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
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?
Annotations already establish readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond the annotations by disclosing that the tool returns 'every recorded event with its digest' and that the purpose is independent verification of the ledger's integrity. This is richer than simply declaring a safe read, though it does not discuss pagination or response size, which are not critical given the tool's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core action ('Fetch the public reputation ledger') and then adding usage guidance. No wasted words; every sentence earns its place. It is appropriately sized for a simple, parameterless read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description is complete. It explains the ledger's purpose, what is returned (events and digests), and when to use it. The mention of independent verification adds valuable context for agent decision-making. There are no significant gaps 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?
The tool has zero parameters, and the schema confirms this with no properties. The description consequently does not need to explain parameter semantics. Per the baseline for 0 parameters, a score of 4 is appropriate. The description's mention of 'every recorded event' implies that no filtering parameters exist, which aligns with 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 clearly states the tool fetches the public reputation ledger and specifies its scope: 'returning every recorded event with its digest.' It distinguishes this from sibling tools (get_issue, get_market, etc.) by focusing on the ledger and its audit purpose. The verb 'Fetch' and resource 'public reputation ledger' are specific 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?
Explicit usage guidance is provided: 'Use this when the user wants to audit REP movement, check a specific event, or confirm the ledger has not been altered.' This directly tells the agent when to invoke the tool, offering clear use cases. Although alternatives are not named, the sibling tools target different resources, making the intended usage obvious.
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 targets a distinct resource or action: fetching challenge, corpus, issue, ledger, market, params, key, settlement, solution; listing issues, tasks, solutions; preparing and submitting work; and describing the protocol. There is no overlap or ambiguity among them.
All tool names follow a consistent verb_noun pattern with lowercase and underscores: get_*, list_*, prepare_*, submit_*, and describe_*. The pattern is uniform and predictable across the entire set.
With 15 tools, the surface is well-scoped for a domain that requires both read and write capabilities. Each tool contributes meaningfully without redundancy, and the count falls within the ideal 3-15 range.
The tool set provides full lifecycle coverage: understanding the write protocol, reading all relevant data (issues, markets, ledger, settlements, solutions, params), preparing work entries, and submitting them. There are no obvious gaps or dead ends for an agent to accomplish its goals.