RequestRepo MCP

by hofill

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
Disambiguation4/5
Most tools have distinct purposes, but some potential confusion exists between 'delete_request' and 'delete_all_requests', and 'set_file' and 'update_files' could overlap. The DNS tools (add_dns, list_dns, remove_dns, update_dns) are clearly differentiated by action, and file/request tools generally target different operations.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern with snake_case throughout. Examples include 'add_dns', 'list_requests', 'update_files', and 'wait_for_request'. There are no deviations in style or convention across the set.
Tool Count4/5
With 16 tools, the count is slightly high but reasonable for a server handling requests, DNS, and files. It covers multiple domains without being excessive, though it might feel heavy compared to simpler servers. The tools appear well-scoped to the server's purpose.
Completeness4/5
The tool set provides good coverage for request management (list, delete, share, wait), DNS operations (add, list, remove, update), and file handling (get, list, set, update). Minor gaps include no explicit 'get_request' tool and limited session management beyond 'session_info', but agents can work around these with existing tools.
Average 2.7/5 across 16 of 16 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Set one file response' implies a write/mutation operation, but the description doesn't reveal what 'set' actually does (creates, overwrites, configures?), whether it's destructive, what permissions are needed, what happens on success/failure, or any rate limits. This leaves critical behavioral traits completely undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words), which could be efficient if it were informative. However, this brevity results in severe under-specification rather than effective communication. While it's front-loaded with the core action, every word fails to earn its place by adding meaningful value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (6 parameters including binary data and HTTP headers), the complete lack of annotations, and the description's failure to explain what the tool does, when to use it, or what parameters mean, this description is completely inadequate. The existence of an output schema doesn't compensate for these fundamental gaps in understanding the tool's purpose and behavior.
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?
With 0% schema description coverage and 6 parameters (2 required), the description provides absolutely no information about what any parameter means or how they interact. Parameters like 'path', 'confirm', 'body_text', 'body_base64', 'status_code', and 'headers' are completely unexplained, leaving the agent to guess their purpose and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set one file response' is essentially a tautology that restates the tool name 'set_file' with minimal elaboration. It doesn't specify what 'file response' means in context, what resource is being set, or how this differs from sibling tools like 'update_files' or 'get_file'. The purpose remains vague despite the tool name providing some clue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools that might handle files or responses (e.g., 'get_file', 'update_files', 'list_files'), but the description offers no context about when this specific tool is appropriate, what prerequisites exist, or when to choose other tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get one file response' implies a read operation but doesn't disclose important behavioral traits like whether this requires authentication, what happens with large files (given the max_bytes parameter), whether it's idempotent, what errors might occur, or what the 'response' format looks like. The description mentions 'response' but doesn't explain what that entails.
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 extremely concise at just four words, which could be appropriate if it were more informative. However, this brevity comes at the cost of under-specification rather than efficient communication. The single sentence is front-loaded but doesn't contain enough substance to justify its existence.
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 a file retrieval tool with 3 parameters, no annotations, and sibling tools that suggest a file management context, the description is inadequate. While an output schema exists (which reduces the need to describe return values), the description doesn't address the tool's role in the ecosystem, parameter purposes, or behavioral characteristics needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters, the description provides no information about any parameters. It doesn't mention 'path', 'decode_base64', or 'max_bytes', leaving the agent to infer their purposes from schema titles alone. The description fails to compensate for the complete lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get one file response' is a tautology that essentially restates the tool name 'get_file'. It doesn't specify what type of file retrieval this performs (e.g., from filesystem, cloud storage, etc.) or how it differs from sibling tools like 'list_files' or 'set_file'. While 'get' implies retrieval, the description lacks specificity about what resource is being accessed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_files' for multiple files or 'set_file' for writing files, nor does it indicate prerequisites, constraints, or appropriate contexts for use. The agent receives no direction about when this specific file retrieval method is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Replace all file responses' implies a destructive mutation affecting multiple items, but doesn't clarify what 'all' encompasses (e.g., system-wide, per-user, or per-session), whether changes are reversible, or what authentication/rate limits apply. The description adds minimal behavioral context beyond the obvious mutation implication.
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 maximally concise at three words with zero wasted language. It's front-loaded with the core action and resource. While under-specified, this isn't a conciseness issue—every word earns its place by stating the essential operation.
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?
For a destructive mutation tool with 2 required parameters, complex nested objects, no annotations, and 0% schema description coverage, the description is severely incomplete. While an output schema exists (which relieves the description from explaining return values), the description fails to address critical context like scope, safety, parameter usage, or differentiation from siblings—making it inadequate for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'files' should contain, the purpose of the 'confirm' boolean, or how the FileResponseInput structure works. With 2 required parameters and complex nested objects, this leaves critical usage details undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Replace all file responses' states a verb ('Replace') and resource ('file responses'), but lacks specificity about what 'file responses' are in this context. It doesn't distinguish from sibling tools like 'set_file' or 'get_file', leaving the exact scope unclear. While not a tautology, it's too vague for effective tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 like 'set_file' or 'list_files'. The description offers no context about prerequisites, appropriate scenarios, or exclusions. This forces the agent to guess based on tool names alone, which is insufficient for reliable decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but discloses almost nothing about behavioral traits. It doesn't mention whether deletion is permanent or reversible, what permissions are required, whether it affects related data, rate limits, or error conditions. For a destructive operation, this is critically inadequate.
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 maximally concise with just three words that directly state the tool's function. There's zero wasted language, and it's appropriately sized for such a simple statement of purpose.
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?
For a destructive operation with 2 parameters and no annotations, the description is severely incomplete. While an output schema exists (which reduces the need to describe return values), the description doesn't address critical context like deletion permanence, permissions needed, or how this differs from sibling deletion tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 2 parameters, the description provides no information about parameter meaning or usage. It doesn't explain what 'request_id' identifies, what format it should be in, or why a 'confirm' boolean is required. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete one request' clearly states the verb (delete) and resource (request), but it's vague about scope and doesn't differentiate from sibling tools like 'delete_all_requests' or 'remove_dns'. It specifies 'one request' which helps distinguish from batch deletion, but lacks specificity about what type of request or system context.
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 about when to use this tool versus alternatives like 'delete_all_requests' for batch operations or 'remove_dns' for different resource types. The description doesn't mention prerequisites, consequences, or appropriate contexts for this deletion operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Resolve' without explaining behavior—e.g., what 'resolve' does (e.g., retrieves data, validates token), potential side effects, authentication needs, or rate limits. It lacks details on return format or error handling, leaving key behavioral traits undisclosed.
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 a single, efficient sentence with no wasted words, making it front-loaded and easy to parse. However, its brevity leads to under-specification, slightly reducing effectiveness despite good structure.
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 4 parameters with 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It doesn't address parameter meanings, behavioral context, or usage scenarios, failing to provide enough context for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'share_token' is, what 'include_raw' or 'include_body' toggle, or how 'max_bytes' affects output. With 4 parameters and no schema descriptions, this is a significant gap in semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resolve a shared request token' states a clear verb ('Resolve') and resource ('shared request token'), but it's vague about what 'resolve' entails—does it retrieve, validate, or process the request? It doesn't distinguish from siblings like 'share_request' or 'get_file', leaving ambiguity in purpose.
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. Siblings include 'share_request' (likely creates tokens) and 'get_file' (retrieves files), but the description doesn't clarify if this is for accessing shared content, verifying tokens, or other contexts, offering no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'optional filtering' but doesn't disclose key behavioral traits: whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior (implied by limit/offset but not explained), or what 'captured' means in context. The description is minimal and lacks necessary operational context for safe use.
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 extremely concise—a single sentence with no wasted words. It's front-loaded with the core purpose. While it lacks detail, every word earns its place by stating the basic action and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, but has output schema), the description is incomplete. The output schema existence means return values needn't be explained, but the description doesn't cover parameter meanings, usage context, or behavioral traits. It's minimally adequate for a simple list tool but leaves significant gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'optional filtering' but doesn't explain what parameters are available or their purposes. The six parameters (limit, offset, request_type, include_raw, include_body, max_bytes) are undocumented in both schema and description, leaving their semantics unclear. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List captured requests with optional filtering' clearly states the verb ('List') and resource ('captured requests'), but it's somewhat vague about what 'captured requests' specifically are. It doesn't distinguish this tool from sibling tools like 'list_dns' or 'list_files', leaving ambiguity about the scope of 'requests' versus other listable resources.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'optional filtering' but doesn't specify scenarios where filtering is appropriate or when to choose this over other list tools like 'list_dns' or 'list_files'. No prerequisites, exclusions, or comparison to siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Add a DNS record' implies a write/mutation operation, but it doesn't disclose important traits like: whether this requires specific permissions/authentication, if changes are immediate or propagate with delay, potential rate limits, what happens on failure, or if the 'confirm' parameter provides a dry-run mode. The description is minimal and lacks operational 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 is extremely concise at just four words, with zero wasted language. It's front-loaded with the core action and resource. While arguably too brief for a tool with 4 parameters and no annotations, it achieves maximum efficiency within its limited scope.
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 (mutation operation with 4 parameters), lack of annotations, and 0% schema description coverage, the description is incomplete. While an output schema exists (which reduces need to describe return values), the description fails to provide necessary context about the operation's behavior, parameter meanings, or integration with sibling DNS tools. For a write operation in a DNS management context, this leaves too many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides only parameter names and types without explanations. The description adds no parameter semantics whatsoever - it doesn't explain what 'domain', 'record_type', 'value', or 'confirm' mean in the context of DNS record addition. For a tool with 4 required parameters and no schema descriptions, this is a significant gap that leaves parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a DNS record' clearly states the action (add) and resource (DNS record), making the purpose immediately understandable. It distinguishes from sibling tools like 'remove_dns' and 'update_dns' by specifying addition rather than deletion or modification. However, it doesn't specify what kind of DNS record system this operates on (e.g., domain registrar, internal DNS server).
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_dns' for checking existing records, 'remove_dns' for deletion, or 'update_dns' for modifications. There's no context about prerequisites, dependencies, or typical use cases for DNS record management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions polling and timeout, which implies a blocking or iterative operation, but fails to specify what constitutes a 'new request', how polling works (e.g., continuous checks), or potential side effects like resource consumption. This leaves key behavioral traits undocumented.
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 extremely concise with a single sentence, front-loading the core action ('Poll for a new request') and constraint ('until timeout'). There is no wasted text, making it efficient and easy to parse, though this brevity contributes to gaps in other dimensions.
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 (polling with 6 parameters), no annotations, and an output schema (which helps but isn't described), the description is incomplete. It lacks details on behavior, parameter usage, and how it fits with siblings, making it insufficient for an agent to fully understand the tool's context and operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It only references 'timeout' implicitly, ignoring other parameters like 'request_type', 'poll_interval_seconds', 'include_raw', 'include_body', and 'max_bytes'. This adds minimal meaning beyond the schema, failing to explain their roles or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Poll for a new request') and the resource ('request'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'list_requests' or 'get_shared_request', which might also involve requests, so it lacks explicit differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an active session or specific conditions, nor does it compare to siblings like 'list_requests' for non-polling access, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates something, implying a mutation, but does not clarify permissions needed, whether the share token is permanent or temporary, rate limits, or what the output contains. This leaves significant gaps in understanding the tool's behavior.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should cover return values) and no annotations, the description is minimally viable but incomplete. It lacks details on parameter semantics, usage context, and behavioral traits, which are needed for a mutation tool. The presence of an output schema prevents a lower score, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with only a parameter named 'request_id' documented. The description does not add any meaning beyond the schema—it does not explain what a 'request_id' is, its format, or where to obtain it. For a single parameter with no schema details, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a share token') and the target resource ('for a request'), which is specific and unambiguous. However, it does not differentiate this tool from its sibling 'get_shared_request', which appears to retrieve shared requests rather than create them.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_shared_request' or other request-related tools (e.g., 'delete_request', 'list_requests'). It lacks context about prerequisites, such as needing an existing request to share, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Replace the full DNS records set' implies a destructive mutation operation, but it doesn't disclose critical behaviors: whether this requires admin permissions, if changes are immediate or propagate slowly, what happens to existing records not included, or if there are rate limits. The description is minimal and lacks necessary operational 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 is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place in conveying the tool's purpose.
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 this is a destructive mutation tool with no annotations, 0% schema description coverage, but with an output schema, the description is inadequate. It doesn't address safety concerns, permission requirements, or operational implications of replacing DNS records. The presence of an output schema helps with return values, but the description should do more to contextualize this high-impact operation.
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 0%, so the description must compensate. It mentions 'full DNS records set' which hints at the 'records' parameter being an array of records, but doesn't explain the 'confirm' parameter or provide details about record structure (type, domain, value). The description adds some context but doesn't fully compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Replace the full DNS records set' clearly states the action (replace) and resource (DNS records set). It's specific about replacing the entire set rather than partial updates, which distinguishes it from potential sibling tools like 'add_dns' or 'remove_dns'. However, it doesn't explicitly differentiate from all siblings like 'update_files'.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'add_dns', 'remove_dns', or 'list_dns', nor does it specify prerequisites, consequences, or appropriate contexts for replacing DNS records versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'List all file responses' but doesn't disclose behavioral traits such as pagination, sorting, filtering, rate limits, authentication needs, or what 'all' entails (e.g., scope, limits). This is a significant gap for a list operation with zero annotation coverage.
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 a single sentence with no wasted words—'List all file responses'—making it highly concise and front-loaded. Every word serves a purpose, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, it lacks context on behavior (e.g., what 'file responses' are, how results are returned) and doesn't differentiate from siblings, leaving gaps in completeness for a list tool.
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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but that's acceptable here. Baseline is 4 for zero parameters, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all file responses' states a clear action (list) and resource (file responses), but it's vague about what 'file responses' means and doesn't distinguish from siblings like 'get_file' or 'list_requests'. The purpose is understandable but lacks specificity about scope or format.
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 like 'get_file' (for individual files) or 'list_requests' (for requests). The description implies it's for listing all files, but it doesn't specify context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action is a deletion but doesn't specify if it's reversible, requires specific permissions, affects other data, or has rate limits. The description adds minimal context beyond the basic action, leaving critical behavioral traits undocumented.
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 a single, direct sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration. Every word earns its place, making it highly efficient.
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 complexity of a destructive operation with no annotations and an output schema (which isn't described in the description), the description is incomplete. It doesn't explain the irreversible nature, session dependency, or what the output might contain. For a tool that deletes all requests, this lack of context is a significant gap.
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 1 parameter and 0% schema description coverage, the description doesn't mention the 'confirm' parameter at all. However, since there are 0 parameters described in the schema, the baseline is 4. The description fails to compensate for the lack of parameter documentation, but the low parameter count keeps it from scoring lower.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('all requests for the current session'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'delete_request' (which deletes individual requests) or 'list_requests' (which lists them), missing full sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active session), exclusions (e.g., irreversible action), or compare to siblings like 'delete_request' for selective deletion or 'list_requests' for verification. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks behavioral details. It implies a destructive operation ('Remove') but doesn't specify if it's irreversible, requires permissions, has rate limits, or what happens on success/failure. The 'confirm' parameter hints at safety but isn't explained, leaving gaps in transparency for a mutation tool.
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 a single, efficient sentence with zero waste—it directly states the tool's purpose and key parameters. It's front-loaded and appropriately sized for a simple tool, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It covers the core action and main parameters but lacks details on behavior, error handling, or output. The output schema mitigates some gaps, but for a destructive tool, more context would improve completeness.
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 0%, so the description must compensate. It mentions 'domain and optional type', covering 2 of 3 parameters, but omits 'confirm'. It adds minimal semantics (e.g., 'optional type' implies record_type can be null) but doesn't explain parameter interactions or effects, resulting in a baseline score due to partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and resource ('DNS records'), specifying the key parameters ('by domain and optional type'). It distinguishes from siblings like 'list_dns' (read) and 'update_dns' (modify), but doesn't explicitly differentiate from 'delete_all_requests' or other deletion tools, keeping it at 4 rather than 5.
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. It doesn't mention prerequisites (e.g., needing existing records), exclusions (e.g., not for bulk deletion), or refer to siblings like 'delete_all_requests' for different contexts. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'List DNS records' implies a read operation, but it doesn't specify whether this requires authentication, returns all records or a subset, includes pagination, or has rate limits. This is a significant gap for a tool with zero annotation coverage.
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 a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and siblings like 'add_dns' and 'update_dns', it lacks context on permissions, scope, or differences from other tools, leaving gaps in completeness for the agent.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied since the schema fully handles parameters, and the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List DNS records' clearly states the verb ('List') and resource ('DNS records'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_files' or 'list_requests' beyond the DNS domain, which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'add_dns', 'remove_dns', and 'update_dns' available, there's no indication of whether this is for read-only operations or how it differs from other listing tools, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('ping') but doesn't explain what happens during execution (e.g., whether it sends a test message, waits for response, or returns latency). It also omits critical details like error conditions, timeout behavior, or whether it affects the connection state.
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 a single, efficient sentence with zero waste. It's front-loaded with the core action and target, making it easy to parse. Every word contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, but with an output schema), the description is minimally adequate. It states what the tool does but lacks behavioral context that would help an agent use it effectively. The presence of an output schema means return values are documented elsewhere, but the description doesn't hint at what the output might contain (e.g., success status or latency).
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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter information, and it correctly doesn't mention any parameters, earning a baseline score of 4 for this simple case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('ping') and the target ('underlying requestrepo websocket connection'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its siblings (like 'session_info' which might also test connectivity), so it doesn't reach the highest score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or suggest other tools for related functions (e.g., using 'session_info' for connection status). This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Return'), but doesn't mention authentication requirements, rate limits, error conditions, or what constitutes 'session info' (e.g., user identity, permissions, expiration). The description is minimal and lacks important 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 is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and a vague 'session info' concept, it lacks important context about what information is returned and under what conditions. The output schema existence prevents a lower score.
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?
The description mentions no parameters, while the schema has one parameter with 0% description coverage. Since there are zero parameters documented in the description, this meets the baseline of 4 for having no parameters to explain. The description doesn't need to compensate for schema gaps because it doesn't reference parameters at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 with a specific verb ('Return') and resource ('session info'), and specifies the scope ('for the active requestrepo client'). It doesn't explicitly differentiate from sibling tools, but the purpose is unambiguous within this context.
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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, typical use cases, or comparison with sibling tools that might also provide session-related information (though none are obviously named as such).
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:

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

Score Badge

Copy to your README.md:

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

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