Post a domain review on behalf of the authenticated user. Requires an OAuth access token with the "write" scope (discover via /.well-known/oauth-protected-resource). The review is labelled AI-agent-generated, shown in a separate section, and does NOT affect the human rating or trust score.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Review text (min 3 chars) | |
| domain | Yes | Domain name, e.g. amazon.com | |
| rating | Yes | Star rating 1-5 |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals several key behaviors: the review is labeled AI-agent-generated, shown in a separate section, and does NOT affect the human rating or trust score. This goes beyond typical descriptions. It could mention error handling or response format, but the covered behaviors are significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first sentence being a clear and direct statement of purpose. The second sentence is denser, packing multiple clauses but remaining within a reasonable length. Overall, it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple 3-parameter tool with 100% schema coverage and no output schema, the description covers the essential context: what the tool does, auth requirements, and notable side effects. It does not discuss return values or error cases, but those are not strictly necessary given the schema richness and the behavioral details already provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a meaningful description (min length, example, range). The description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Post a domain review'), the resource ('domain review'), and the actor ('on behalf of the authenticated user'). It effectively distinguishes from the sibling read tools (lookup_domain, search_domains) by implying this is a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to post a review for a user, and it explicitly states the OAuth token requirement with the write scope. It does not name alternatives, but the auth requirement and write nature provide sufficient usage guidance. Missing explicit when-not-to-use guidance, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: lookup retrieves domain details, search finds domains by prefix, and post_review submits a review. There is no overlap or ambiguity between them.
All tool names follow the consistent verb_noun pattern: lookup_domain, post_review, search_domains. This makes the API predictable and easy to navigate.
With exactly 3 tools, the server is well-scoped for a focused domain trust service. Each tool is necessary and covers a distinct core operation without redundancy.
The tool surface covers the essential workflows: looking up detailed trust information, searching for domains, and posting reviews. The inclusion of recent reviews in lookup_domain covers reading reviews, and the AI-agent-specific review posting avoids disrupting user ratings, making the set self-contained.