Approve a pending access request on your space, issuing the grant with optional rights, persistence, or world-mutation limits. Enables owner-controlled authorization.
Approve a pending access request on a space you own, issuing the grant (optionally narrowing rights / persistence / world-mutation). Owner-governed.
| Name | Required | Description | Default |
|---|---|---|---|
| rights | No | ||
| requestId | No | ||
| sessionId | No | ||
| worldMutation | No | ||
| persistenceMode | No |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It clearly indicates the action is owner-governed (authorization) and that the grant is issued, implying a state change and potentially side effects. It mentions optional narrowing of rights, persistence, and world-mutation, which are useful behavioral traits. It lacks detail on reversibility or audit trails, but the core behavior is disclosed.
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 a single succinct sentence that front-loads the purpose and then adds optional capabilities. No wasted words; every clause adds meaning.
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 this is a mutating tool with zero annotations and no output schema, the description should explain authorization requirements, expected parameters, and potentially the effect of each option. It only covers high-level behavior and leaves key parameters unexplained. An agent would struggle to call it correctly.
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 0%, so the description must explain all parameters. It only hints at 'optionally narrowing rights / persistence / world-mutation', which vaguely corresponds to rights, persistenceMode, and worldMutation. It completely omits requestId and sessionId, which are likely critical for identifying the request and session. This is a significant gap.
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 uses a specific verb ('Approve') with a clear resource ('pending access request on a space you own') and adds the outcome 'issuing the grant'. It distinguishes from siblings like noetic.deny_request and noetic.grant by focusing on approving a request, though it could be clearer about the distinction from noetic.grant.
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?
It states the tool is for approving pending access requests, implying it is used after review. It mentions 'a space you own', indicating the ownership requirement. However, it doesn't explicitly compare to deny_request or grant, so an agent might confuse it with grant. The context is present but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.