Skip to main content
Glama
Sign In
Gemmein MCP Server

Gemmein MCP Server

Official
by gemmeinhq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

explain_rule

Read-only

Retrieve details on Gemmein's seven access rules to design collections or debug runtime denials. Returns contracts, uses, and data-leak mistakes; omit rule for full cheat-sheet and cross-cutting law.

Instructions

Call while DESIGNING a collection — which rule fits this data? — or when a rule refuses something at runtime. One of the seven rules (private, shared, admin_write, public_read, community, addressed, direct) returns its exact access contract, what it is right for, and the mistakes that leak data. Call with no rule for the all-seven cheat-sheet plus the cross-cutting law, including what NO rule supports (team/group/workspace scope, per-user visibility inside a rule) — if the app needs those shapes, that is a fit gap to report to your human, never something to approximate with client-side filtering.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "explain_rule"
  }
}

Input Schema

NameRequiredDescriptionDefault
ruleNothe rule to explain; omit for the all-rules cheat-sheet

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

readOnlyHint=true already establishes this as a safe read, and the description adds meaningful behavioral context: it discloses the return payload (access contract, fit, leak mistakes), enumerates the seven rules and the cross-cutting law, and describes what NO rule supports (team/group/workspace scope, per-user visibility). It stops short of stating whether the explanations are static or context-dependent, but the disclosure goes well beyond the annotation.

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?

It is front-loaded with the call trigger and packs the payload description into two dense sentences with little wasted wording. The final clause about fit gaps is long and parenthetical-heavy, slightly blurring the structure, but each part carries actionable content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one optional enum parameter, full schema coverage, and no output schema, the description carries the return-value burden itself and does: it spells out what each invocation returns, the all-rules fallback, and the boundary of what the rules can express. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the enum values are documented, so the baseline is 3. The description adds real meaning beyond the schema by explaining the omission behavior ('call with no rule for the all-seven cheat-sheet plus the cross-cutting law') and by enumerating the seven rule names inline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource — it explains one of seven named rules, returning that rule's 'exact access contract, what it is right for, and the mistakes that leak data', plus the no-arg cheat-sheet variant. An agent can tell exactly what it gets back and how it differs from a generic guide/reference sibling without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names both trigger conditions explicitly: 'Call while DESIGNING a collection' and 'when a rule refuses something at runtime'. It also supplies a when-not rule ('never something to approximate with client-side filtering') and routes unsupported shapes to a human instead of a workaround, so the agent knows what NOT to use this for.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools