AgenticSettle Verify

Official

by agenticsettleio

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: verify_output submits content for verification, check_verdict retrieves a specific result, get_insights tracks agent performance, list_verifications searches records, submit_feedback and submit_appeal handle user-side actions. No two tools have overlapping functionality.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (verify_output, check_verdict, get_insights, list_verifications, submit_feedback, list_criteria_templates, get_manager_alerts). The naming is predictable and clearly conveys the action and resource involved.
Tool Count5/5
With 9 tools, the set is well-scoped for the domain of AI output verification. Each tool serves a necessary function in the verification, retrieval, feedback, and appeal lifecycle without redundancy or bloat.
Completeness5/5
The tool surface covers the full verification lifecycle: submitting output, retrieving results, listing history, checking appeals, tracking agent performance, providing feedback, and browsing templates. No obvious gaps exist for the stated purpose of verifying AI-generated content.
Average 4.6/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
- 16 commits in the last 12 weeks
- Last stable release on July 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
Add a glama.json file to provide metadata about your server.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as readOnlyHint=true and openWorldHint=true, so the description's job is lighter. It adds value by explicitly listing the full return dict structure, including conditional fields like 'outcome' and their possible values (e.g., 'UPHELD'|'OVERTURNED'), which is beyond what annotations provide. The 'Free tier' mention adds business context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a concise one-line purpose, then follows with structured Args and Returns sections that are easy to parse. Every line adds value, though the return format listing is verbose; it could be condensed or moved to an output schema, but it's still efficient for agent use.
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 simplicity (one parameter), the annotations covering read-only and open-world behavior, and the output schema already present, the description is complete. It explains the required parameter's origin, documents the full return structure with enum values and conditional fields, and mentions cost tier. No gaps remain.
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?
With 0% schema description coverage and only one parameter, the description compensates well by explaining that the 'appeal_id' must come from 'submit_appeal', which adds semantic meaning beyond the schema's bare type/required definition. The description fully covers the parameter's origin and role.
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 retrieves an appeal's status and tamper-check result. It specifies the exact resource ('appeal') and action ('check'), and includes the free tier mention which is distinctive. Among siblings like 'submit_appeal' or 'verify_output', this tool's purpose is unambiguous.
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 explicitly notes that the 'appeal_id' parameter must be the one returned by 'submit_appeal', which gives clear usage context. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'check_verdict' or 'get_insights', though the purpose is distinct enough to imply usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and open-world. The description adds valuable behavioral context: 'Free tier' (no cost), returns records 'in reverse chronological order', and details the exact fields returned. This goes beyond what annotations provide, though rate limits or auth specifics are missing.
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 a one-line summary, a dedicated 'Args' section with bullet points, and a 'Returns' section. Every sentence adds value, no fluff. Front-loaded with the core purpose.
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 has 7 optional parameters, no schema descriptions, and an output schema (though present in description not as JSON), the description covers all parameter details, default values, valid values, return structure, and ordering. It is sufficiently complete for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each of the 7 parameters: valid enum values for verdict and tier, ISO 8601 example for dates, range and default for limit, and default for offset. This adds essential meaning that the input schema alone lacks.
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 verb 'List', the resource 'VOP verification records', and adds distinguishing context like 'Free tier' and 'optional filters and pagination'. This differentiates it from sibling tools like verify_output and check_verdict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its clear listing function but does not explicitly tell when to use this tool versus alternatives. It mentions 'Free tier' as a hint but provides no exclusions or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's 'Retrieve' verb is consistent. It adds valuable behavioral context: the settlement field is always None, the audience parameter has specific restrictions, and it lists the return keys. This goes beyond the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, but includes a Returns section that lists keys. It is well-structured with clear sections (purpose, usage, args, returns). It could be slightly more concise, but the structure aids readability.
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 presence of an output schema, the description effectively covers the tool's purpose, parameter usage, and return values. It provides enough context for an AI agent to understand when and how to use the tool, and what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates. It explains report_id as 'the verification ID returned by verify_output', and audience details the 'agent' and 'customer' values with their purposes, plus a warning against 'admin'. This adds significant meaning beyond the bare schema.
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 specifies 'Retrieve an existing VOP verification verdict by report ID', using a clear verb and resource. It distinguishes this tool from siblings like verify_output (which creates a verification) and list_verifications (which lists), making the purpose unambiguous.
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 explicitly states to use the report_id returned by verify_output, providing clear context for when to invoke this tool. It also offers guidance on the audience parameter, warning against using 'admin'. While it doesn't explicitly list when not to use or alternatives, the context is sufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (only readOnlyHint=false, etc.), so the description carries the burden. It discloses that feedback is 'reviewed weekly and drives product improvements', and mentions 'Free tier'. It also specifies the return format. This is sufficient for a non-destructive feedback tool, though it could mention latency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: purpose, usage guidance, parameter list, return value. It is comprehensive but not overly verbose. Every sentence adds value. A slight reduction in parameter detail could be possible if the schema had descriptions, but given the 0% coverage, the current structure is appropriate.
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 (5 parameters, 3 required, no nested objects) and the presence of an output schema, the description covers all necessary aspects: purpose, usage, parameter details, and return format. It also provides example values for optional parameters. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), so the description fully compensates. It explains rating (1-5 satisfaction), category with explicit enum meanings, comment (max 2000 chars), tool_name (with example), and report_id (purpose). This is highly valuable for correct usage.
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 explicitly states 'Submit feedback about this MCP server or a VOP verification result', which is a specific verb+resource. It clearly distinguishes from sibling tools like verify_output, check_verdict, and submit_appeal, which handle verification or appeals rather than general feedback.
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 advises 'Use after any tool call to report issues, request features, or share what worked well', providing clear context for when to use this tool. It also explains the meaning of each category. However, it does not explicitly state when not to use it or list alternatives, though the distinction from siblings is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: 'Aggregates verdict counts and average score across this agent's verify_output history.' It also explains the return format in detail, including the non-obvious note about pass_rate_pct being 0-100 not 0-1. This goes beyond 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 concise—two short paragraphs plus structured Args/Returns. It is front-loaded with the purpose, every sentence adds value, and the structured format improves readability. No 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?
Given the simple input (one parameter) and the presence of an output schema, the description covers input, output, and usage context completely. It explains the aggregation behavior, the return fields with types and ranges, and the intended use case. The sibling tools are diverse, but the description sufficiently situates this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must carry the full burden. It explicitly documents the sole parameter agent_id with 'The agent identifier to look up.' This adds meaning beyond the schema's type and title. The return values are also fully described, compensating for any missing schema detail.
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 retrieves aggregated VOP performance statistics for an agent. It specifies the action ('Retrieve') and resource ('VOP performance statistics'), and distinguishes it from sibling tools like verify_output and check_verdict by noting it aggregates historical data for evaluating an agent's track record.
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 provides explicit usage guidance: 'Use to evaluate an agent's track record before relying on its output.' This gives a clear when-to-use context. It does not explicitly list alternatives or when not to use, but the purpose is distinct enough from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the description's burden is lowered. The description adds value by explaining the 'Free tier' access constraint and detailing the return structure, which goes beyond the annotations. No contradictions or omissions noted.
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 concise and front-loaded: the first sentence states the core purpose. The subsequent paragraphs for Args and Returns are well-structured, adding detail without redundancy. Every sentence contributes value, and the entire description fits in a few lines.
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 one optional parameter and no required params, and the description covers the purpose, parameter behavior in detail, and the full return structure. An output schema exists but the description still explains the return format, which is helpful. There are no gaps: the agent knows exactly what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates by explaining the 'domain' parameter: it is optional, filters by domain name, and matches domain equality or template_id prefix match, with an example. This is comprehensive and adds meaning far beyond the bare schema.
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 verb 'list' and the resource 'bundled domain criteria templates', and further clarifies that these show what a well-specified verification rubric looks like. This distinguishes the tool from siblings like 'list_verifications' or 'verify_output', 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 provides clear context by stating it lists templates and mentions 'Free tier', implying it is always available. While it does not explicitly state when not to use it or point to alternatives, the sibling tools are sufficiently distinct, so an agent can infer when to use this tool without confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only (readOnlyHint=false) and is open-world (openWorldHint=true), not idempotent, and not destructive. The description adds significant behavioral detail: the verdict applies only to the submitted content, repeated calls on unchanged input don't converge, and each call counts against daily quota. This exceeds what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (primary use case, verdict semantics, score variance, return format). It is concise for the amount of information provided, though slightly verbose in parts (e.g., the note about LLM confidence could be merged).
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 parameters, open-world behavior, return of multiple fields), the description is complete. It explains how to handle revisions, score variance, and optional parameters. The presence of an output schema reduces the need to describe return values, but the description still covers all key behavioral aspects.
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 0%, so no parameter descriptions exist in the schema. The description compensates well by explaining each parameter's purpose, including the sla parameter with supported keys and examples. However, it doesn't explicitly describe agent_id or the structure of the return value beyond what the output schema could provide, though the description of the return dict is thorough.
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 that the tool verifies AI-generated output using VOP, distinguishing it from simple self-assessment. It explicitly differentiates from siblings like check_verdict, get_insights, etc., by focusing on the verification of content with grounded web search.
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 provides explicit guidance on when to use this tool (verifying any AI-generated content before final presentation) and what not to rely on (LLM's own confidence). It also explains edge cases like content revisions requiring new submissions and score variance due to live search.
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 discloses behavioral traits beyond annotations: it explains the 'Free tier' limitation, the always-account-scoped nature, and the background context of Manager AI continuously monitoring for anomalies. These add significant value beyond the readOnlyHint and openWorldHint annotations, providing safety and operational clarity.
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 efficient and well-structured: a one-sentence purpose, a brief explanation of the tool's context, scoping note, then an Args section using bullet format, and a Returns section. Every sentence adds value 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?
Given the tool's complexity (4 optional parameters, no enums, output schema exists), the description covers all needed context: parameter details, return structure with keys, background behavior, and account scoping. It leaves no ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates. It explains each parameter in detail: domain with common values, severity levels, status options, and limit range with default. This adds critical meaning beyond the bare schema, enabling correct agent usage.
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's purpose: 'List Manager AI oversight alerts (incidents) for this account.' The verb 'List' and resource 'Manager AI oversight alerts' are specific. It distinguishes itself from siblings by focusing on alerts, while siblings like 'verify_output' and 'check_verdict' 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 provides clear context: it lists alerts scoped to the account's API key and notes the absence of tenant-scoping parameters. It implicitly conveys when to use (to see alerts) but does not explicitly state when not to use or mention alternatives, though sibling diversity makes differentiation straightforward.
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 provide 'openWorldHint: true' and 'destructiveHint: false', but the description far surpasses them by detailing the hash-check mechanism, tamper check interpretation, return structure with appeal window and recomputation details, and the fact that a hash mismatch doesn't necessarily mean tampering. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections for the core purpose, behavioral detail, and Args/Returns. The description is front-loaded with a concise summary ('Dispute a VOP verdict...'). However, it is slightly verbose with the detailed tamper check explanation, which could be tightened without losing clarity. Still, every sentence earns its place.
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 complexity of the tool (5 parameters, 3 required, no schema coverage, outputs with nested dicts) and sibling tools that include verification functions, the description is remarkably complete. It covers all parameters, return values explicitly (even without an output schema from the service, the description provides the structure), and accounts for time windows and error conditions. No gaps remain for an AI agent to safely invoke it.
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 coverage is 0%, so the description must fully compensate. It explains each parameter in the Args section: 'verification_id' as 'the report_id from the disputed verify_output/check_verdict call', 'request_content' and 'result_content' with hash-matching constraints, and optional params like 'appellant' and 'reason' with examples. The only minor gap is that 'appellant' examples don't clarify whether it's used for identification or routing, but overall it adds significant meaning beyond the schema.
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 states a specific verb ('Dispute') and resource ('VOP verdict'), clearly distinguishing this tool from siblings like 'verify_output' and 'check_verdict'. It adds the unique behavior of a 'deterministic tamper check' to further clarify its purpose.
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?
Explicitly states when to use (to dispute a verdict) and what not to do (reconstructed text will be rejected). Mentions time window constraints and provides clear prerequisites (exact original inputs). Alternatives like 'verify_output' are implied through context, making the guidance comprehensive.
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:

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

Score Badge

Copy to your README.md:

[![agenticsettle-mcp MCP server](https://glama.ai/mcp/servers/agenticsettleio/agenticsettle-mcp/badges/score.svg)](https://glama.ai/mcp/servers/agenticsettleio/agenticsettle-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/agenticsettleio/agenticsettle-mcp'

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