Core Content Services MCP Server
OfficialServer Quality Checklist
Latest release: v1.0.4
- Disambiguation4/5
Most tools have distinct purposes focused on specific operations (e.g., checkout vs. checkin, create vs. update), but there is some overlap between lookup_documents_by_name and repository_object_search for document retrieval, and between get_document_properties and get_class_specific_properties_name for property access. The descriptions help clarify, but an agent might occasionally misselect between these similar tools.
Naming Consistency5/5Tool names consistently follow a verb_noun pattern with snake_case throughout (e.g., cancel_document_checkout, create_document, get_document_properties). There are no deviations in naming conventions, making the set predictable and easy to parse.
Tool Count3/5With 26 tools, the count is high but reasonable for a comprehensive content management system covering documents, folders, classes, versions, and search. However, it borders on being heavy, which could overwhelm agents or lead to redundancy, as seen with multiple lookup and property tools.
Completeness5/5The tool set provides complete CRUD/lifecycle coverage for documents and folders, including version management, class handling, annotations, and search. There are no obvious gaps; prerequisites are clearly documented, and the domain of content services is thoroughly addressed without dead ends.
Average 3.9/5 across 26 of 26 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims to return a Folder object or ToolError, but it introduces a parameter (folder_properties) not in the schema, suggesting an update behavior that is misleading. No annotations exist, so the description carries full burden, but it lacks true behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is not concise; it includes a leading 'Description:' and rambles about an unrelated update parameter. It could be much shorter and clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and an output schema (not shown but implied), the description covers the basic return value and error. However, the incorrect parameter mention and lack of details on what properties are returned make it less complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description adds some context for identifier (GUID), but it also mentions an extra parameter (folder_properties) that is not in the schema, causing confusion and reducing reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it gets folder information by ID, which aligns with the name 'get_folder_detail' and distinguishes it from sibling tools like create_folder or update_folder. However, it also mentions 'folder_properties' for updating, causing slight confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_folder_documents or update_folder. The description does not provide context for when to fetch folder details or when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It states the return value (folder id or error) but does not disclose behavioral traits such as whether the operation is reversible, permissions required, or side effects on the document. 'Unfile' implies removal from folder but no explicit safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured but verbose, including a Python-style docstring with parameter and return documentation. The first sentence is concise, but the param and return sections could be streamlined. It's adequate but not optimized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the existence of an output schema, the description provides basic functional context. However, it lacks information about the tool's role in the content repository workflow, such as when to unfile vs. delete, or how it interacts with check-in/check-out states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so parameter descriptions are the only source. The description adds minimal meaning: folder_id_or_path can be ID or path, document_id is just ID. This is slightly more than the schema types but lacks detail on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Unfile a document from a folder'. It identifies the resource and verb. However, it does not differentiate from siblings like 'file_document' or 'checkin_document', though the inverse nature provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It mentions required parameters and error if omitted, but no context about prerequisites, when not to use, or relationships to other tools like 'file_document'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details parameters and return types (Document or ToolError) but does not disclose that checkin modifies the document (creates new version), requires permissions, or has side effects like version increment. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear sentence but becomes verbose with docstring-style parameter lists. Some parameter descriptions are redundant (e.g., 'Check-in action parameters for the document'). Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 parameters and an output schema, the description lacks critical context: it doesn't mention that checkin requires a prior checkout, that it creates a new version, or how it fits with sibling tools. The return description is vague ('Document object with its updated properties').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value for the identifier parameter by explaining reservation_id vs document_id priority, which is not in the schema. For other parameters, it merely restates names without additional semantics. The schema already provides detailed nested descriptions, so baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Checks in a document' and lists parameters, making the action and resource explicit. It differentiates from siblings like checkout_document, but does not explicitly distinguish from other document tools such as update_document_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use checkin versus alternatives (e.g., checkout or cancel checkout). It omits prerequisites such as the document being checked out, and does not explain typical workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects. It only states it deletes a folder but does not specify whether contents are also deleted, permission requirements, or if the operation is reversible. Inadequate for a delete action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes docstring formatting and a param line that could be integrated more cleanly. It is not excessively long, but could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing critical context: what happens to subfolders/files, whether it's a soft or permanent delete, permission requirements, and error conditions beyond a generic ToolError. Incomplete for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'id_or_path' has 0% schema description coverage; the description repeats it is an identifier/path and that omitting it causes an error. It does not explain format, examples, or how to differentiate between id and path, adding minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Deletes a folder in the content repository', specifying the verb and resource. Distinguishes from sibling tools like create_folder, update_folder, and get_folder_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites (e.g., folder must be empty), and no when-not-to-use conditions. For a destructive operation, this is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It mentions creating a 'referential containment relationship' and returns either relationship ID or ToolError, but does not disclose permissions, idempotency, or whether the document/folder must exist beforehand.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the action, but includes a docstring-style parameter table and returns section. Could be condensed; the parameter info could be integrated into the prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 simple parameters and an output schema. The description covers basic purpose and return value, but omits context like error conditions, required existence of referenced objects, or any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides clear parameter explanations (document_id_or_path as unique identifier or path). It adds meaning beyond the bare schema, though it does not elaborate on format or validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'files a document to a folder', which is a specific verb+resource. It distinguishes itself from sibling tools like 'unfile_document' (opposite) and 'create_document' (creates a document, not filing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'create_document' or 'unfile_document'. The description lacks any context about prerequisites (e.g., document must already exist) or why you'd choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only states it is a retrieval operation. Does not disclose any behavioral traits such as authorization, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise docstring format; covers param and returns clearly. Could be more compact but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and output schema present (not shown), description explains input and return type. Lacks differentiation from sibling and behavioral context, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% parameter descriptions, but the description provides a clear explanation of the 'class_symbolic_name' parameter, adding needed semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'retrieves' and resource 'searchable properties of a class'. Distinguishes from sibling 'get_class_property_descriptions' by specifying 'only'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'get_class_property_descriptions'. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must clarify side effects and behavior. It only states it checks out a document and mentions return/error behavior, but lacks details on document locking, reservation creation, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with clear sections for each parameter and return value. It is not overly verbose; each sentence adds useful information, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains parameters and return values but misses broader context like prerequisites (document existence, permissions) or interaction with sibling tools (checkin/cancel). The output schema exists but is not detailed, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the docstring thoroughly explains each parameter (identifier as ID/path, document_properties to update, checkout_action parameters, download_folder_path optional with interactive prompt) adding context the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Checks out a document in the content repository.' It uses a specific verb and resource, and it distinguishes from sibling tools like cancel_document_checkout and checkin_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, such as requiring the document to exist or user permissions, nor does it suggest when to use checkin or cancel after checkout.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds transparency by noting that multiple text extracts are concatenated and that an empty string is returned if none exist. However, it does not disclose other behavioral aspects like access rights or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear bullet points for the parameter and return value. Every sentence provides useful information with no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown), the description appropriately omits detailed return format but still explains concatenation and empty string behavior. For a single-parameter tool, the description covers essential aspects adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description adds crucial meaning by explaining that 'identifier' can be a document ID (GUID) or a path (e.g., '/Folder1/document.pdf'). It also notes the parameter is required, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieves') and the resource ('document's text extract content'), making the purpose unambiguous. It is specific enough to distinguish from sibling tools like get_document_properties or get_document_versions, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, which would help an agent decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It only says 'Retrieves', suggesting a read operation, but does not disclose safety, idempotency, permissions, pagination, or potential limits. The return type is mentioned but incompletely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The param docstring is slightly redundant but does not bloat the description significantly. Could be tightened further.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and an output schema, the description covers the basic operation. However, it fails to clarify whether the listing is recursive or only direct children, and does not mention limits or ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It merely restates the parameter name ('The folder id or path') without explaining format, examples, or constraints, adding minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retrieves a folder's contained documents.' This is a specific verb-resource pair that clearly distinguishes from sibling tools like 'get_folder_detail' (which retrieves folder metadata) and various lookup/search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a folder id or path is available, but lacks explicit guidance on when not to use (e.g., when needing recursive listing or cross-folder search). No alternatives are mentioned despite numerous sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool can return a Document object on success or a ToolError on failure, but it does not detail side effects, permissions required, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose sentence and separate param/returns notes. It is not overly verbose, though the :param/:returns formatting adds slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and an existing output schema, the description covers the return type but does not detail the Document object's fields or mention side effects. It is adequate but has gaps in explaining what 'updated properties' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'identifier' as a string, with 0% coverage. The description adds significant meaning by explaining it can be a reservation_id or document_id, with priority on reservation_id. This compensates well for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'cancels' and the resource 'document checkout', making the tool's purpose explicit. It distinguishes itself from sibling tools like checkout_document and checkin_document by specifying the cancellation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to cancel a checkout, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No prerequisites or common failure scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the tool updates a folder (a mutation) and returns a Folder object or ToolError. However, it does not mention side effects, authorization needs, rate limits, or whether the operation is reversible. More context on the impact of updates would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes a block of prerequisites in all-caps that could be streamlined. The parameter list is clear but repeats some information from the schema. Overall, it is not overly verbose but could be more efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides return values and prerequisites, but lacks details on error scenarios beyond ToolError, permissions, or potential side effects. Given the complexity of a mutation tool with 3 parameters and an object input, it is minimally complete but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'identifier' can be a GUID or path, 'class_identifier' is optional for changing class, and 'folder_properties' includes name and other properties. This adds meaning beyond the schema, especially for the identifier parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates an existing folder in the content repository with specified properties.' This provides a specific verb ('Update') and resource ('folder'), distinguishing it from creation or deletion. However, it does not explicitly differentiate from similar tools like 'update_document_properties' or 'create_folder'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists prerequisites in order: 'you MUST call two other tools first... determine_class... get_class_property_descriptions.' This provides strong guidance on when and how to use the tool, including a necessary sequence, which is above and beyond typical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it requires prerequisites, uses CBR search, returns ToolError if CBR not enabled, and explains that additional properties narrow results. With no annotations provided, this adds substantial behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with prerequisites, parameter descriptions, and an example. However, it contains some redundancy and could be more concise, justifying a score of 3.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites, parameter usage, behavior, and includes an example. The presence of an output schema reduces the need to detail return values. Minor omissions like max_results behavior are not critical, so the description is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), but the description compensates by explaining the search_term parameter (content vs metadata search), the search_parameters structure, and the role of search_class and search_properties. The example further clarifies usage, making parameter semantics clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches documents by content and metadata criteria. The name 'document_search' and the focus on documents distinguishes it from sibling 'repository_object_search'. However, it does not explicitly differentiate from similar tools, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The prerequisites section explicitly lists required prior tools in order (determine_class and get_searchable_property_descriptions), and states that the search class must be a document class. This provides clear context for when to use this tool, though it lacks explicit alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool returns a list of matching documents or a ToolError, and mentions confidence scores. It implies a read-only operation but does not explicitly declare non-destructive behavior or other traits like rate limits or side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is split into parameter docs and a summary paragraph. The summary is concise, but the parameter section is verbose and somewhat repetitive. The overall structure is clear but could be more streamlined without losing essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters and an existing output schema, the description covers parameter usage, error behavior, and expected output format (list of DocumentMatch objects). It also references a sibling tool for a subtask. It is largely complete, though details of the output schema are not elaborated (but output schema itself exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. For keywords, it adds constraints (up to 3 words, avoid common words) and clarifies usage. For class_symbolic_name, it explains when to use it and how to obtain the value via determine_class, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a search to lookup documents by name, distinguishing it from siblings like 'document_search' (general search) and 'lookup_documents_by_path' (path-based). The verb 'lookup' and resource 'documents by name' are specific. Additional parameter guidance reinforces purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific guidance on when to use the optional class_symbolic_name parameter and refers to determine_class tool as a prerequisite. However, it does not explicitly state when not to use this tool versus alternatives (e.g., general search or path lookup), leaving some ambiguity for the AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the tool retrieves objects, implying a read operation. However, it does not mention permissions, idempotency, or what happens if prerequisites are not met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose and repetitive, with redundant sections ('PREREQUISITES IN ORDER' and then the description). It could be streamlined by integrating prerequisites and the main description more concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, multiple siblings, no annotations), the description covers purpose, prerequisites, and return structure. It lacks examples but is otherwise adequate for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters well. The description adds the return structure (independentObjects, properties) and clarifies AND logic for search_properties, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves repository objects other than Document instances, distinguishing it from document_search. It also lists detailed prerequisites that define its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires calling determine_class and get_searchable_property_descriptions first, providing clear workflow guidance. It implies this tool is for non-Document objects, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true. The description adds detail on return values (deleted Document id or ToolError), enhancing transparency beyond annotations. However, it does not disclose if deletion is permanent or affects version numbering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two main sections (param and returns) and front-loads the action. It is efficient without wasted words, though slightly long due to the param explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While it covers action, parameter, and return value, it fails to specify how 'identifier' identifies the version rather than the document. This ambiguity reduces completeness for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that 'identifier' can be a document ID (GUID) or path with an example, adding significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Deletes a specific document version in the content repository,' using a specific verb and resource. It distinguishes the tool from siblings like 'delete_version_series' which deletes all versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (deleting a specific version) but does not explicitly guide when to use versus alternatives like 'delete_version_series' or mention prerequisites. Usage context is implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it returns a list, which is basic; no mention of side effects, permissions, or safety. Adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no wasted words, front-loaded with the purpose. Efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a simple output, the description is sufficient. It explains the return value with an example. Could mention possible limitations but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; baseline is 4. The description adds context by stating the output and provides an example, which is useful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists root class types, with a specific verb and resource. It provides an example and mentions usage before list_all_classes, but does not explicitly differentiate from other list tools among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'should be called first to get a list of valid root class names before using the list_all_classes tool.' This is clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses creation behavior, default parameter values, and return types (Document object or ToolError). With no annotations, it adequately describes behavioral traits, though lacks detail on side effects like permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a prerequisites header, parameter list, and returns section. Not overly verbose, though the param descriptions could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, parameter details, defaults, and return values. Given the complexity (6 parameters, nested objects, optional fields), the description is fairly complete, though it could mention output schema fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaning for all parameters: explains defaults (class_identifier defaults to 'Document'), constraints (file_in_folder_identifier starts with '/'), and usage hints (checkin_action: 'checkinMinorVersion should always be included').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a document in the content repository. It distinguishes from sibling tools like 'create_folder' and 'checkin_document' by specifying the action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists prerequisites in order (determine_class, get_class_property_descriptions) and notes default values, but does not mention when not to use this tool or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the tool retrieves all properties including system/hidden and returns CachePropertyDescription objects. It does not discuss side effects or auth needs, but for a read-only retrieval this is adequate. It adds context beyond the schema but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief purpose statement, followed by usage warnings in bold (IMPORTANT and DO NOT), then clear parameter and return documentation. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only retrieval) and the presence of an output schema, the description covers all necessary aspects: what the tool does, when to use it, what the input is, and what the output represents. It is fully adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds a clear explanation of the sole parameter 'class_symbolic_name' as 'The symbolic name of the class to retrieve properties for', which provides meaning beyond the empty schema. This is sufficient for a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves ALL properties of a class including system properties. It distinguishes from siblings by specifying it is meant for general document updates and explicitly warns against using it for property extraction workflows, which differentiates it from tools like get_searchable_property_descriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use ('for general document updates where you need to see ALL properties') and when-not-to-use ('DO NOT use for property extraction workflows'). However, it does not name specific alternative tools for the excluded use case, stopping short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adequately discloses behavior: it retrieves all versions without modification. It explains the scope of the version series and the nature of the response, making the tool's effect clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but somewhat verbose, especially the return structure. While clear, it could be more concise without losing essential information. However, it is well-organized and front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and the presence of an output schema, the description provides sufficient context. It explains the return structure in detail, compensating for the output schema not being shown. It covers the essential use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly explains the 'identifier' parameter, noting it can be a document ID or path. This adds significant meaning beyond the input schema's type definition (string). No parameters are undocumented in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all versions in the version series for a specified document. This verb+resource definition distinguishes it from sibling tools like delete_document_version or get_document_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that this tool returns past, current, and future versions in the same series. It provides context for when to use it, though it does not explicitly exclude alternatives or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite missing annotations, the description reveals that matching is based on containment names rather than document names, and it specifies the return type (list or ToolError). This adds valuable behavioral context beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and includes a docstring-like block followed by a separate paragraph, making it less concise and somewhat repetitive. While front-loaded with the prerequisite, it could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main aspects: prerequisite, parameter details, return type, and error handling. It omits minor details like case sensitivity or ordering, but overall it is sufficiently complete given the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description thoroughly explains both parameters: 'keywords_at_path_levels' is clarified as a list of lists with constraints on word count and common words, and 'class_symbolic_name' is described with its default behavior and when to specify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool 'execute a search to lookup documents based on where they are filed in a folder hierarchy' and distinguishes itself from sibling 'lookup_documents_by_name' by noting the path separator character as an indicator for its use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool (user uses '/') and includes a prerequisite to call 'determine_class' first, but does not explicitly mention when to avoid it or compare with other siblings like 'document_search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool performs substring matching, returns up to 3 matches or a ToolError, and includes the return structure (class_name and score). This is transparent for a search tool, though it does not explicitly declare the operation as read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative with a clear structure: a main purpose statement, an IMPORTANT note, and parameter descriptions. It is not excessively long, but some redundancy exists (e.g., the return format is mentioned twice). Still, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters and an output schema, the description covers the input semantics, prerequisite, and return behavior (list of up to 3 matches or ToolError). It does not detail the ClassMatch structure beyond field names, but the output schema likely handles that. Overall, it provides sufficient context for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant value by explaining each parameter: 'root_class: The root class to search within (eg. "Document", "Folder")' and 'keywords: Up to 3 words from the user's message that might contain the class's name.' It also adds a constraint ('Up to 3 words') not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find classes that match the given keywords by looking for substring matches in class names and descriptions.' This distinguishes it from sibling tools like list_root_classes (which lists all root classes) and get_class_property_descriptions (which gets properties of a specific class).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit prerequisite: 'To get a list of all valid class names that can be used with this tool, you MUST first call the `list_root_classes_tool` tool.' It also explains the parameters root_class and keywords. However, it does not explicitly state when not to use this tool or provide alternatives beyond the prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the tool only updates properties and does not change the class, and describes success/failure returns. However, it does not mention authentication needs, potential side effects, or rate limits, which would be expected for a mutation tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a bold 'Prerequisites' section, a clear description paragraph, and a structured parameter list using colons. Every sentence adds necessary information without redundancy. It is concise but comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, many subfields, and a return object) and no annotations, the description covers prerequisites, purpose, limitations, parameters, and return types. It references the output schema ('returns a Document object') and handles common failure cases. This is complete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has extensive descriptions for the 'document_properties' subfields, giving high coverage. The description adds value by explaining the 'identifier' parameter (document ID or path) and listing the key properties. This complements the schema well, providing additional context beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'update' and resource 'document properties', and clearly distinguishes from 'update_document_class' by stating it does not change the document's class. This differentiates it among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'Prerequisites' section listing two tools that must be called before use, and explicitly states when not to use the tool (to change a document's class, use 'update_document_class'). This provides clear when/when-not and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the creation behavior, parameter defaults (e.g., UUID generation), and error handling via ToolError. It could mention side effects or permissions, but the provided detail is sufficient for a read-creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a prerequisite note, parameter list, and return documentation. It is slightly lengthy due to parameter details, but the front-loaded prerequisites are excellent. Some redundancy exists (param descriptions repeated), but it is organized for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites, parameters, behavior, and return values comprehensively. An output schema is implied, and the return shape is described. Minor omissions like potential error types or constraints could be added, but the tool is sufficiently documented for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by documenting all five parameters with types, required status, and defaults (e.g., class_identifier defaults to 'Folder'). It also explains the id auto-generation and folder_properties structure, adding significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a folder in the content repository, distinguishing it from siblings like create_document or update_folder. It specifies the API interface and provides parameter details, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists two prerequisite tools (determine_class and get_class_property_descriptions) that must be called in sequence before using create_folder. This provides clear guidance on when and how to use the tool, which is excellent for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description reveals that success returns the deleted version series ID and failure returns a ToolError, adding behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with core purpose, and structured logically with parameter and return documentation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and no output schema, the description covers all necessary information: what it does, what it returns, and how to prepare the input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains the parameter (GUID) and how to obtain it, adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool deletes an entire version series (all versions of a document), distinguishing it from sibling delete_document_version which deletes a single version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on obtaining the required version_series_id via get_document_property if missing, but does not explicitly state when to avoid using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions return types (Document object or ToolError) but omits details like access permissions, caching behavior, or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear sections: purpose, usage note, parameter detail, and return values. Every sentence adds value, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one parameter, straightforward retrieval), the description covers all necessary aspects: purpose, usage context, parameter semantics, and return behavior. The presence of an output schema means return details are available separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a string 'identifier' with no description. The description adds crucial context: it can be a GUID or a file path, with an example. This compensates fully for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('retrieves'), the resource ('document's properties'), and the method ('by ID or path'). It distinguishes itself from sibling tools like document_search or repository_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use this tool (only when retrieving by ID or path) and provides a direct alternative ('repository_search') for other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: warns about potential property loss if the new class lacks certain properties, states it only changes class (not properties), and describes return values (Document object or ToolError).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bolded PREREQUISITES, a warning, and clear sections for parameters and returns. It is informative but slightly lengthy; could be more concise while retaining all essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters and no annotations, the description covers prerequisites, side effects, parameter details, and return values. It differentiates from siblings and includes error details (ToolError). Highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides clear explanations for both parameters—'identifier' can be a GUID or path, and 'class_identifier' is the new class—thus fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Changes a document's class in the content repository,' uses a specific verb+resource, and distinguishes from sibling tools like update_document_properties by emphasizing it only changes class and not properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists prerequisites (must call list_all_classes or determine_class first) and provides guidance on when to use each. Also clarifies this tool does not update properties and directs to update_document_properties for that purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ibm-ecm/ibm-content-services-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server