get_accessThe access settings of your presentation: its level ("open", "public", "private"), who was given access (and which role), and the pending requests.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The presentation's slug (its address: /movie/<slug>/). |
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | open, public or private. | |
| grants | No | ||
| pending_requests | No |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "grants": {
+ "items": {
+ "properties": {
+ "role": {
+ "type": "string"
+ },
+ "since": {
+ "description": "ISO 8601 date and time.",
+ "type": "string"
+ },
+ "user": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "level": {
+ "description": "open, public or private.",
+ "type": "string"
+ },
+ "pending_requests": {
+ "items": {
+ "properties": {
+ "agent": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "description": "ISO 8601 date and time.",
+ "type": "string"
+ },
+ "id": {
+ "type": "integer"
+ },
+ "message": {
+ "type": "string"
+ },
+ "presentation": {
+ "description": "Slug of the presentation.",
+ "type": "string"
+ },
+ "role": {
+ "description": "view or edit.",
+ "type": "string"
+ },
+ "status": {
+ "description": "pending, approved or declined.",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "user": {
+ "description": "Who asks.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "level"
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful content-level detail: it lists the three access levels and mentions pending requests, which helps interpret the output. But it doesn't say whether 'pending requests' are only visible to owners/admins or how authorization affects the result. This adds context but leaves a gap around permissions.
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?
A single efficient sentence. However, it's noun-phrase front-loaded with the resource rather than the action, which is slightly less direct for an agent scanning for a verb. No filler.
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?
With annotations covering safety, an output schema present, and the only parameter fully described, the description does enough. It names the access levels and mentions pending requests, which prepares the agent for the output. It could mention permissions scope (whose view), but that is minor.
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 the single slug parameter is fully documented in the schema. The description adds no meaning beyond that. Baseline 3 is correct when the schema does the heavy lifting.
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 explains what the access settings contain (level, who has access, roles, pending requests) but begins with 'The access settings of your presentation' – a noun phrase that restates the title rather than stating a retrieval action. The verb 'get' is only in the tool name. An agent must infer the operation. It doesn't distinguish this from list_access_requests or set_access.
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?
No guidance on when to use this versus siblings like get_presentation or list_access_requests. The description doesn't say whether it returns only the caller's access or all users' access. No prerequisites or conditions are stated.
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.