attester-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct task: code research, work verification, SLA monitoring, counterparty checks, rubric grading, and package/symbol checks. The oracle_* tools are clearly separated from the attester_* demo tools, and even within each family purposes are unambiguous.
Naming Consistency2/5
Naming is inconsistent across the set: oracle_* uses a mix of verbs (research, verify_work, judge) and nouns (watchtower_report, spend_check), while attester_* follows a different entity-first pattern (package_exists, symbol_signature, version_diff). No uniform verb_noun convention is maintained.
Tool Count4/5
9 tools is a reasonable count for an attestation server, though it splits into two distinct families (oracle_ paid services and attester_ free demos) which makes the set feel slightly broader than one focused domain. Each tool earns its place, so the count is justified.
Completeness4/5
The core lifecycle is well covered: research, verification, grading, spend checks, and dependency diffing. Minor gaps exist, such as no direct tool to list watchtower targets or inspect raw package metadata, but these are edge cases that don't break workflows.
Average 4.7/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, open-world, idempotent), the description discloses important behavioral traits: rate limits (25 calls/day per client IP), quota reset time, behavior when over quota (redirects to paid route), error behavior for unresolvable versions (422 error, never partial diff), and the signed attestation output. This adds significant context beyond what annotations provide.
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 uses clear section labels (WHAT, WHEN, WHEN NOT, COST, OUTPUT) to front-load the core purpose and provide scannable details. Every sentence contributes value—purpose, usage guidance, error behavior, pricing, and output structure—with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 required parameters, output schema, rate limits, paid routes, signed attestation), the description is remarkably complete. It covers the operation, usage context, failure modes, cost structure, and output keys, leaving little ambiguity for an agent deciding whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all four parameters with clear descriptions (ecosystem, package, from_version, to_version) at 100% coverage. The description does not add additional parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
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 opens with a precise action: "symbol-level diff between two pinned versions of one package" and enumerates the specific outputs (added, removed, changed signatures, new deprecations, breaking/additive/neutral classification). This clearly distinguishes it from sibling tools like attester_package_exists or attester_symbol_signature, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case ("before upgrading a dependency, or when reviewing what an upgrade breaks") and a 'WHEN NOT' statement about unresolvable versions. However, it does not name alternative tools for cases where a diff cannot be performed, so it lacks the explicit alternative guidance that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals cost per call ($0.10 USDC), latency range (~2-6s), the independent verification pipeline, and the attestation mechanism, all beyond the annotations' readOnly/openWorld/idempotent hints. It gives critical operational details without contradicting annotations.
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 labeled sections (WHAT, WHEN, WHEN NOT, COST, LATENCY, OUTPUT) make the dense information scannable and front-loaded. There is no redundant wording; every section provides necessary information for an agent to decide and invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, exclusions, cost, latency, and output structure, with annotations covering safety. However, the optional 'context' input parameter is not explained, which is a minor completeness gap given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implicitly defines 'query' as the coding question but does not explain the optional 'context' parameter. With 0% schema description coverage, some compensation exists (e.g., query semantics), but the context parameter's purpose remains unclear, leaving a notable gap.
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 clearly states the tool answers coding questions (library/API usage, error diagnosis, best practices) and provides real citations with a signed attestation. This specific verb+resource distinguishes it from siblings like oracle_verify_work or oracle_watchtower_report, and the contrast with web search clarifies its niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes WHEN and WHEN NOT sections: use when you need a grounded, cited answer mid-task and are willing to pay; avoid for open-ended code generation, private/proprietary docs, or when a free unverified answer suffices, citing web search as the alternative. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description goes well beyond by disclosing cost limits (25 calls/day, shared quota, reset time), a paid fallback route, and the exact output shape including proof/attestation fields. This adds real decision-making context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with WHAT/WHEN/WHEN NOT/COST/OUTPUT, front-loaded with the core purpose. Every sentence adds distinct information (cost, quota, typosquat, output). No fluff or redundancy, despite length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool complexity is moderate due to rate limits, paid route, and typosquat behavior. The description covers all of these, gives the full output shape (also in output schema), and includes cost details. Combined with strong annotations, the description is complete for selecting and invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (name and ecosystem) with examples. The description reinforces these but adds little new syntactic detail—its main additions (typosquat_adjacent, cost) relate to output and usage rather than parameter semantics. Baseline 3 applies since schema carries the load.
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 opens with a clear WHAT: 'checks whether a package name really exists in PyPI or npm.' This is a specific verb+resource (packages in public registries) and inherently distinguishes from sibling tools like attester_symbol_exists. It adds the typosquat behavior, further clarifying its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN: 'before installing or importing a package a model suggested' with supporting evidence (5-20% hallucination rates). Explicit WHEN NOT: 'for private packages outside the public registries.' This gives the agent clear conditions for use and exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses the static analysis ceiling (cannot detect runtime-created symbols), free-tier rate limits (25 calls/day shared across attester_* tools), quota fallback to a paid route, and a detailed output structure including proof/attestation fields. This adds substantial 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses labeled sections (WHAT/WHEN/WHEN NOT/COST/OUTPUT) to pack information into a scannable format. Every sentence carries distinct information—no filler—making the length justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with a full output schema, the description covers purpose, usage, limitations, cost, and output fields. It is self-contained and leaves no major questions about how to invoke or interpret results.
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?
Schema covers 100% of parameters with descriptions. The tool description adds that 'symbol' refers to functions, classes, and constants and reinforces the 'latest indexed version' default for the version parameter, slightly enriching the schema. Baseline 3 plus one for the semantic clarification.
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 opens with 'WHAT: checks whether a symbol (function, class, constant) exists in a package at the latest indexed version' — a specific verb and resource with clear scope. It also mentions closest-match suggestions, distinguishing it from sibling tools like package_exists and symbol_signature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'WHEN' (before calling an API you are not sure exists) and 'WHEN NOT' (dynamically created symbols), offering clear usage guidance. However, it does not name alternative tools directly, so it stops short of a full 5 on the alternatives criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, but the description adds valuable context: free shared quota (25 calls/day per client IP, reset 00:00 UTC), over-quota behavior pointing to paid route, and clarification of 'signature' vs 'attestation_signature'. No contradictions with annotations.
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 is well-structured with labeled sections (WHAT, WHEN, WHEN NOT, COST, OUTPUT, Note) and front-loaded with the purpose. Every sentence adds relevant information, and the output field list is clearly separated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description explains key output fields and the critical distinction between 'signature' and 'attestation_signature'. It also includes cost, quota, and sibling-tool distinctions, making it complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is documented in the schema itself. The description adds slight context (e.g., 'resolved at a pinned version') but not enough to push beyond the baseline for full schemas.
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 clearly states the tool returns 'the exact signature, structured params, docstring summary, and deprecation status for one symbol' with version resolution, which is specific and distinguishes it from sibling tools like attester_symbol_exists or attester_version_diff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit WHEN guidance ('before writing a call against an API you have not used at this version') and WHEN NOT ('PyPI type annotations are unavailable'), as well as cost/alternative routing. This fully addresses when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly and idempotent, but the description adds valuable behavioral context: cost per check, latency, the policy that 'An unknown payee is always caution, never clear,' and a detailed output structure. This goes well beyond annotations without contradicting them.
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 uses labeled sections (WHAT, WHEN, WHEN NOT, COST, LATENCY, OUTPUT) that are concise and front-loaded. Each sentence adds useful information without redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, but the description still provides a helpful preview of return fields. It also covers cost, latency, usage boundaries, and a key policy caveat. The inclusion of sibling tool references and cost information makes it operationally complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—both payTo and amount_usd are well-described. The description adds some contextual framing (e.g., 'pre-payment' and 'raising a payment limit') but does not introduce parameter-specific meaning beyond the schema. This aligns with the baseline for high schema coverage.
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 clearly states a specific verb+resource: 'pre-payment counterparty check. Given a 0x address or URL, returns a clear/caution/avoid verdict with per-source evidence... and a signed attestation.' It distinguishes from siblings by explicitly pointing to oracle_verify_work for judging delivered work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN clauses: 'before sending any x402 payment to a service you have not paid before, or before raising a payment limit.' WHEN NOT is also explicit: 'for services you already trust, for judging delivered work (use oracle_verify_work), or as a guarantee.' This provides clear alternatives and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive, and the description adds valuable behavior beyond that: cost ($0.15 USDC, x402, free tier), latency range, output structure, and the meaning of 'abstain'. This is rich, non-redundant context that helps the agent anticipate side effects and results.
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 is long but tightly organized with labeled sections (WHAT, WHEN, WHEN NOT, COST, LATENCY, OUTPUT). Every sentence provides distinct and necessary information, and the most critical what-it-does is front-loaded. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 params, no schema descriptions, and an output schema, the description covers purpose, usage conditions, exclusions, cost, latency, output structure, and the abstain semantics. It addresses both selection and invocation contexts comprehensively, leaving very little to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero description coverage, and the description does not explain the structure of the `job` or `spec` objects. It mentions three job domains but not how to encode them, leaving parameter usage ambiguous. The description compensates only partially; an agent would still need examples or field-level semantics to invoke correctly.
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 opens with 'WHAT: independently checks another agent's work' and enumerates specific domains (citation support, code correctness, dataset/schema conformance). It clearly distinguishes a verification oracle from sibling research/report/spend/judge tools, and it specifies the unique output (verdict + signed attestation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHEN' section lists concrete scenarios (before paying for subcontracted work, before merging agent-produced content) and 'WHEN NOT' gives explicit exclusions (already trusted work, subjective judgments, non-Python code). This provides strong guidance on when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds valuable behavioral context: reports are aggregated over 24h, probes run every 30 minutes, reports are pre-computed (~1s latency), EIP-191 signed, and there is a cost of $0.05 USDC with 3 free reports. No contradictions with annotations.
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 is well-organized with clear labels (WHAT, WHEN, WHEN NOT, COST, LATENCY, OUTPUT) and every sentence provides distinct, useful information. It is concise for the amount of context it delivers, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage boundaries, cost, latency, output shape, and limitations. The presence of an output schema reduces the need to explain return values, and the description goes beyond what is required, making it fully complete for a 1-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'service', and the schema already provides its description ('Host or URL substring of the watched service'). The tool description does not add additional parameter-level detail, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'WHAT: returns the latest signed SLA report for a watched x402 service' and enumerates the exact output fields (uptime_pct, price_match_pct, current_verdict). It clearly distinguishes from siblings by naming oracle_verify_work as the tool for work products, and clarifies the report is for SLA health, not real-time status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides WHEN ('before routing paid traffic to an x402 service you do not control, or when checking whether a service still charges its advertised price'), WHEN NOT ('for real-time health', 'for services not yet watched', 'for verifying work products'), and names an alternative tool (oracle_verify_work). This is exemplary guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial context beyond these: cost ($0.10 USDC), latency (~1s to ~30s), deterministic grading behavior, the literal interpretation of the rubric, score bands, and output details (signed attestation). This enriches the agent's understanding of side effects, resource usage, and response characteristics without contradicting any annotation.
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 is organized with clear labeled sections (WHAT, WHEN, WHEN NOT, COST, LATENCY, OUTPUT, Bands), making it easy to scan and parse. Every sentence serves a distinct purpose—purpose, usage guidance, exclusions, cost, latency, output format, and thresholds—with no fluff or redundant restatement of schema/annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, an output schema, and rich annotations, the description covers all critical operational aspects: exact use cases, alternatives, cost, latency, determinism, score bands, and output structure. The presence of an output schema means return values need not be exhaustively documented, but the description still summarizes the key output fields and thresholds, leaving no significant gaps.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context by explaining that the judge is 'literal and grades exactly what you write,' which directly informs how the rubric parameter should be constructed, and ties the weight parameter to the returned per-criterion weighted score. This goes slightly beyond the schema's structural descriptions.
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 opens with 'WHAT: grades an agent output against your rubric and returns a 0-100 weighted score with per-criterion evidence and a signed attestation,' which is a specific verb+resource statement that immediately clarifies the tool's function. It further distinguishes itself from the sibling tool oracle_verify_work by explicitly naming the alternative for citation truth-checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'WHEN' and 'WHEN NOT' sections, listing concrete use cases (accepting/rejecting deliverables, ranking candidate answers, logging QA receipts) and exclusions (subjective taste, citation truth-checking alone, vague rubric). It also names the specific alternative tool, oracle_verify_work, for one of the exclusions, providing clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![attester-mcp MCP server](https://glama.ai/mcp/servers/maminihds/attester-mcp/badges/card.svg)](https://glama.ai/mcp/servers/maminihds/attester-mcp)

Score Badge

Copy to your README.md:

[![attester-mcp MCP server](https://glama.ai/mcp/servers/maminihds/attester-mcp/badges/score.svg)](https://glama.ai/mcp/servers/maminihds/attester-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/maminihds/attester-mcp'

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