@aauth/praca

Official

by aauth-dev

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation5/5
Each tool has a distinct purpose: find_resources searches the registry while list_resources shows local additions; list_operations provides summaries while get_operations fetches full schemas; invoke and reset_tokens serve unique actions. No two tools overlap in a way that would confuse an agent.
Naming Consistency4/5
Most tool names follow a consistent verb_noun snake_case pattern (find_resources, add_resource, list_resources, etc.), but 'invoke' is a lone verb without an object, which is a minor deviation from the established convention.
Tool Count5/5
With 8 tools, the set is well-scoped for managing AAuth resources and their operations. It covers discovery, local management, operation introspection, invocation, and token reset without unnecessary bloat.
Completeness5/5
The tool surface provides end-to-end coverage: resource discovery and CRUD (find/add/list/remove), operation exploration (list/get schemas), invocation (invoke), and testing support (reset_tokens). No obvious gaps that would block typical workflows.
Average 4/5 across 8 of 8 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 42 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals important runtime behavior: automatic auth URL opening, the need to re-invoke after auth, and the special async.receive return value 'subscribe_requires_subagent'. It also notes that no resources are added yet, setting expectations for usage.
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 the core purpose and then provides relevant operational details in a compact form. The 'Currently added resources' note is a useful contextual addition, and there is no redundant filler.
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?
The tool has five parameters, no output schema, and no annotations, yet the description covers the auth flow and a special return case. It does not explain return values for regular operations, error behavior, or how resource/op_id values are obtained, leaving notable gaps for a generic invoke tool.
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 coverage is 0%, so the description must compensate, but it only names path_params, query, and body without explaining their formats or roles. It adds no meaning for the required resource and op_id parameters, beyond what the schema already shows.
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 'Invoke an operation on a resource', which identifies the verb and resource. It does not explicitly distinguish this from sibling tools like list_operations or find_resources, but the action 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical guidance on passing path_params, query, and body, and explains the authorization retry flow: 'call invoke again after authorization completes'. However, it does not state when to choose this tool over alternatives, such as listing operations first or managing resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses useful traits: returns summaries only, keeps token cost flat, and includes a kind field. But it omits error behavior, pagination, side effects, and the significance of 'no resources added yet', which appears to be a transient state rather than tool behavior.
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 opening sentence is front-loaded and the query explanation is concise. The final line about 'currently added resources' does not describe tool behavior and seems like a state note, which reduces conciseness and clarity.
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?
The description covers the core purpose and return type (summaries with kind), but lacks details on resource parameter semantics, return fields, error cases, or output format. With no output schema or annotations, the description is not fully self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The query parameter is well described with matching semantics and an example. However, the required 'resource' parameter is only implied to be a resource, with no guidance on its format or how to identify valid resources. Since schema description coverage is 0%, the description should compensate more.
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 lists operations exposed by a resource, with a specific verb and resource. It distinguishes from siblings like list_resources and get_operations by specifying it returns summaries only and that schemas come from get_operations.
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 explains the query parameter's two modes (free-text and path prefix) and explicitly mentions that get_operations should be used for schemas, which is a clear alternative. However, it does not explicitly state when not to use this tool or provide comprehensive when-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only operation ('fetch') and discloses a token-cost concern, which is a behavioral trait. However, it does not mention whether resources must be added first, error behaviors, or any side effects, leaving notable gaps. The status line about 'no resources added yet' adds a dynamic state but not stable 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the purpose clearly stated in the first sentence. The second sentence about current resources is arguably useful but feels like a status update rather than a durable behavior note. No redundant phrasing, but it could be tighter.
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?
For a tool with 2 params and no output schema, the description explains what it does and distinguishes it from a sibling. However, it does not describe the return structure, error cases, or the dependency on add_resource. The note about 'no resources added yet' is a hint but not a full explanation. Overall, adequate but with clear gaps.
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 explains that 'operations' correspond to op_ids and mentions 'resource', giving general meaning. However, it lacks detail on the format or specific values expected (e.g., are op_ids names or IDs?), and does not clarify what qualifies as a resource. This is sufficient for a basic understanding but not comprehensive.
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 fetches full schemas (params, request body, response) for one or more operations, using a specific verb and resource. It explicitly distinguishes itself from sibling list_operations by noting that schemas dominate token cost, 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 provides clear context by separating this tool from list_operations and explaining the reason (schemas dominate token cost). This implies when to use this tool vs the alternative, though it does not explicitly state when not to use it or offer other alternatives. The 'currently added resources' note hints at a prerequisite but is not phrased as guidance.
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?
With no annotations, the description carries the full burden. It discloses the destructive nature ('clear all stored upstream OAuth tokens') and a key non-effect ('without touching PS consent state'). This gives the agent a clear picture of the tool's impact, though it omits irreversibility details and any return value.
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 first two sentences are concise and purposeful. However, the third line 'Currently added resources: no resources added yet' is irrelevant and confusing, appearing to describe system state rather than the tool. This extraneous sentence detracts from the overall structure.
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?
For a simple tool with one parameter and no output schema, the description covers the core purpose, usage, and a behavioral nuance. However, it lacks parameter semantics, does not mention what the tool returns (if anything), and includes the confusing 'no resources' statement, leaving the description incomplete in key areas.
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 schema has a single required 'resource' string with no description (0% coverage). The description only says 'for a resource,' adding minimal meaning. It does not explain what a resource is, how to specify it, or point to related tools like find_resources. The description fails to compensate for the schema's lack of parameter guidance.
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 action: 'Clear all stored upstream OAuth tokens for a resource.' This is a specific verb+resource combination that distinguishes it from siblings like find_resources, add_resource, or invoke, which deal with resource management or operations rather than token resets.
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?
Provides explicit context for when to use: 'Use during testing to force a fresh upstream OAuth flow without touching PS consent state.' This clarifies the intended scenario (testing) and what outcome to expect, though it does not name alternative tools or explicitly state when not to use it.
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?
With no annotations, the description carries the load. It discloses important side effects: no grant revocation and transparent re-add behavior, plus the local-only scope. It does not mention permissions or error handling, but for a simple removal this is significant 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 first two sentences are concise and informative. The final sentence 'Currently added resources: no resources added yet' appears to be a state artifact and adds no value, detracting from an otherwise lean description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and missing output schema, the description covers purpose, scope, and key behavioral caveats. It is incomplete on parameter format and what happens if the resource isn't present, but these are minor for a simple removal 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?
The schema has one required parameter 'resource' with no description, and the description does not explain its format (e.g., name vs ID). Since schema coverage is 0%, the description should compensate but does not.
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 removes a resource from the local set, using the specific verb 'Remove' and identifying the resource scope. It also contrasts with the Person Server grants, distinguishing its scope from revocation.
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 is agent-proxy-local only and explicitly states it does NOT revoke user grants, which signals when not to use this tool. It also mentions re-adding behavior, implying safe removal. However, it does not name an alternative tool for revocation, so it falls short of explicit alternative guidance.
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?
No annotations are provided, so the description carries the full burden. It clearly indicates a read-only search operation ('Search', 'Returns') and explains the return tagging (`added: true`). While it does not explicitly state that it makes no modifications, the semantics strongly imply a non-mutating operation.
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 core description is one sharp sentence covering purpose and return behavior, with a second sentence providing current state context. While concise, the second sentence is a state snapshot that may become stale and is not a tool behavior, slightly reducing focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and no output schema, the description adequately covers the search scope, query semantics, and result tagging. It lacks explicit result field details or usage edge cases, but the essential behavior is well described.
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 only provides a property `query` with no description. The description explains the query as a free-text search against name/description, giving concrete meaning to the parameter and fully compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search', identifies the resource as the AAuth registry's discoverable resources, and specifies the free-text query mechanism against name/description. This clearly distinguishes it from sibling tools like list_resources and add_resource.
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 the tool is for searching the registry but does not explicitly state when to use it over list_resources or add_resource, nor does it provide alternative guidance. It is a clear purpose statement but lacks explicit when-to-use or when-not-to-use criteria.
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?
With no annotations, the description carries the full burden of explaining behavior. It discloses that the agent proxy canonicalizes the input, fetches the well-known doc, validates, and picks vocabularies, and it explains post-add states. It does not cover error scenarios or idempotency, but the disclosed details go well beyond a minimal description.
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 mostly concise and well-structured, front-loading the purpose and then adding input details and post-conditions. However, the final sentence 'Currently added resources: no resources added yet' appears to be dynamic state or a placeholder, which does not belong in a static tool description and slightly detracts from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers purpose, input, process, and outcomes comprehensively. It omits return value and error handling, but given the simplicity and the detail provided, it is nearly complete. The extra state sentence adds confusion but not a major 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?
The schema has one parameter ('resource') with no description, so the tool description must compensate. It does so by explaining the accepted formats (bare host, host:port, full URL) and noting that the agent proxy canonicalizes. This adds meaningful meaning beyond the raw 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 tool's purpose: to add an AAuth resource to the local set. It uses a specific verb ('Add') and resource ('AAuth resource'), and it is distinct from sibling tools like list_resources and remove_resource.
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?
Provides clear context on how to use the tool, including accepted input formats (bare host, host:port, or full URL) and what happens after adding (immediate invokability or auth flow). It does not explicitly mention alternatives or when not to use, but the guidance is strong enough to warrant a 4.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states what the tool returns (name, description, access_mode, last_used, vocabulary count) and explicitly notes its safety and performance traits ('Cheap; safe'). This adds meaningful context for an agent.
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 two concise sentences that are front-loaded with purpose and return information. Every word contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list tool, the description is adequately complete: it enumerates the return fields and provides usage guidance. The lack of pagination details or ordering doesn't significantly impede an agent's understanding, given the tool's straightforward nature.
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 zero parameters, so the baseline is 4. The description adds value by elaborating on the output rather than parameters, which is appropriate since there are none to document.
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 uses a specific verb ('Return') and identifies the resource ('your locally added resources'), clearly stating what the tool does. It also lists the specific fields returned, which distinguishes it from sibling tools like find_resources by confirming it lists all local resources rather than searching.
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 notes 'Cheap; safe to call anytime,' providing clear context on when it's appropriate to invoke the tool (i.e., it's low-cost and safe for frequent use). However, it does not explicitly discuss alternatives or exclusions, so it stops short of full comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![proxy MCP server](https://glama.ai/mcp/servers/aauth-dev/proxy/badges/card.svg)](https://glama.ai/mcp/servers/aauth-dev/proxy)

Score Badge

Copy to your README.md:

[![proxy MCP server](https://glama.ai/mcp/servers/aauth-dev/proxy/badges/score.svg)](https://glama.ai/mcp/servers/aauth-dev/proxy)

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/aauth-dev/proxy'

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