read_team_spaceRead one file from the team space by its name (list_team_space gives the names). Returns the text of a text file, up to 64 KiB, and a link to the whole file that works for 15 minutes. Only for a session signed in for a team.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | the file's name in the team space, as list_team_space gives it |
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| name | Yes | ||
| note | No | ||
| text | No | ||
| truncated | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, non-destructive, not idempotent). The description adds non-obvious operational traits: a 64 KiB text cap, a link that expires after 15 minutes, and the team-session auth requirement. These are exactly the behaviors an agent cannot infer from structured fields.
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?
Three tight sentences, front-loaded with the action, followed by the return characteristics and then the access constraint. No filler or repetition of the title.
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?
An output schema exists, so return values need not be detailed, yet the description still summarizes the payload and its limits. Size cap, link lifetime, name sourcing, and auth precondition together cover everything needed to call this 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 coverage is 100% and there is only one parameter, so the schema already carries the syntax. The description still adds value by naming list_team_space as the authoritative source of valid names, which is more than the schema's own phrasing conveys.
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?
States a specific verb (Read) and a precisely scoped resource (one file from the team space), plus the identifying key (its name). It is clearly separable from list_team_space, upload_to_team_space, and the project-oriented siblings without opening any schema.
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?
Explicitly routes the agent to list_team_space to obtain valid names and states a hard precondition ('Only for a session signed in for a team'). It does not spell out when a team-space read is preferable to, say, get_project, but the context is clear enough to select correctly.
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.