Loading ToolBench
The Nuxeo MCP server presents a mixed quality profile. It has 8 well-structured tools with mostly complete input schemas using Pydantic models with Field annotations. However, several tools lack comprehensive parameter descriptions, output schemas are not explicitly documented, and error handling is minimal. Tool naming follows verb_noun conventions (get_repository_info, get_children, search, execute_operation), which is a strength. The server uses Pydantic Field annotations for most parameters, providing type information via Python type hints, but descriptions are often terse (e.g., 'list children of a folder document' is only 34 characters). No tool descriptions state whether operations are idempotent, retryable, or destructive beyond the Risk labels. Output schemas are inferred from return type hints but not explicitly documented for LLM guidance. The execute_operation tool, which performs write operations, lacks confirmation or dry-run capability.
Execute a Nuxeo Operation with the specified parameters and input
list children of a folder document
Get a document by path or UID from the Nuxeo repository
Get information about document types and schemas defined in the Nuxeo server
Get information about available Automation Operations in the Nuxeo server
Get information about the Nuxeo repository
Output schemas not explicitly documented for LLM context. Return type hints exist in code (Dict[str, Any]) but LLMs cannot parse Python type hints from tool definitions, they need JSON Schema output descriptions in the tool definition itself. This forces LLMs to infer output structure through trial and error.
Parameter descriptions are terse and lack context. Examples: 'list children of a folder document' (34 chars, below 50-char minimum for clarity), 'reference can be either a uuid or a path' (lacks example of each). Descriptions should explain WHAT, WHEN to use, and FORMAT/CONSTRAINTS.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Get detailed information about schemas defined in the Nuxeo server
search document using a NXQL query
execute_operation (WRITE risk) lacks confirmation or dry-run capability. Agents can invoke arbitrary Nuxeo operations without reversibility safeguards. No error handling guidance for failed operations.
Error handling not documented. No tool description explains what errors are possible, whether they are retryable, or what the LLM should do on failure (e.g., 'If search returns no results, try a broader NXQL query').
Result limits not enforced or documented. search() defaults to pageSize=20 but no description states the maximum, and no guidance on pagination strategy. get_children and get_operations could return unbounded results, risking context window exhaustion.
get_children accepts 'ref' (string, uuid or path) but does not document the expected format of each. LLMs may pass invalid paths or malformed UUIDs without guidance on what constitutes a valid path (absolute? relative? must start with '/'?).
Tool descriptions do not state whether operations are idempotent. An LLM retrying a failed execute_operation call risks duplicate side effects if the operation is not idempotent (e.g., duplicate document creation).