Anytype MCP Server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific resources (objects, spaces, properties, tags, types, collections, members, templates) and actions (create, get, list, update, delete, add/remove, search). No ambiguity exists between tools like anytype_get_object vs anytype_list_objects or anytype_create_property vs anytype_update_property. The descriptions reinforce distinct operations.
Naming Consistency5/5All 33 tools follow a perfect verb_noun pattern with the prefix 'anytype_' and snake_case throughout. The pattern is consistent: anytype_[action]_[resource] (e.g., anytype_create_object, anytype_get_space, anytype_list_tags). No deviations in style or convention exist across the toolset.
Tool Count4/5With 33 tools, the count is slightly high but reasonable for a comprehensive content management system covering spaces, objects, properties, types, tags, templates, members, and collections. Each tool appears to serve a specific purpose in the domain, though some consolidation might be possible (e.g., add/remove from collection could be one tool).
Completeness5/5The toolset provides complete CRUD/lifecycle coverage for all core domain entities: spaces, objects, properties, types, tags, templates, and members. It includes create, get, list, update, and delete operations for each, plus search, collection management, and view handling. No obvious gaps exist; agents can perform full workflows without dead ends.
Average 2.8/5 across 33 of 33 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Actualiza' implies a mutation/write operation, but the description doesn't disclose any behavioral traits: no information about permissions required, whether changes are reversible, rate limits, side effects, or what happens when properties are updated. For a mutation tool with zero annotation coverage, this is completely inadequate.
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?
While the description is brief (one Spanish phrase), this represents under-specification rather than true conciseness. The single sentence doesn't earn its place by providing meaningful guidance beyond the tool name. A truly concise description would still convey essential context about what kind of property is being updated and when to use this tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 7 parameters, no annotations, and no output schema. The description provides minimal information - just a tautological restatement of the tool name. For a tool that modifies properties in what appears to be a complex system (Anytype), the description should explain what properties are, what aspects can be updated, and the implications of changes. The current description is completely inadequate for the tool's complexity.
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?
Schema description coverage is 100%, so all 7 parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Actualiza una propiedad existente' (Updates an existing property) is a tautology that essentially restates the tool name 'anytype_update_property' in Spanish. It doesn't specify what kind of property (object property, space property, etc.) or what aspects are updated. While it distinguishes from creation/deletion tools by mentioning 'existing', it doesn't clearly differentiate from similar update tools like 'anytype_update_object' or 'anytype_update_space'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 this tool versus alternatives. There are multiple update tools in the sibling list (update_object, update_space, update_tag, update_type), but the description doesn't indicate this is specifically for updating properties rather than other entities. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Crea una nueva propiedad' implies a write/mutation operation but provides no information about permissions required, whether the creation is reversible, rate limits, error conditions, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
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 extremely concise - a single Spanish phrase 'Crea una nueva propiedad'. While this is under-specified for the tool's complexity, it's not verbose or poorly structured. Every word contributes to the core meaning, though that meaning is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool (property creation) with no annotations, no output schema, and 8 parameters. The description is completely inadequate given the complexity - it doesn't explain what happens after creation, what the property affects, error conditions, or behavioral constraints. The agent would struggle to use this tool correctly based solely on the description.
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?
Schema description coverage is 100%, so all 8 parameters have descriptions in the schema. The tool description adds no additional parameter information beyond what's already documented in the input schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Crea una nueva propiedad' (Creates a new property) is a tautology that essentially restates the tool name 'anytype_create_property'. It doesn't specify what kind of property (object property, space property, etc.) or what resource it operates on. While it distinguishes from deletion/update siblings by being a creation tool, it doesn't differentiate from other creation tools like 'anytype_create_object' or 'anytype_create_type'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 this tool versus alternatives. There's no mention of prerequisites, when this should be used instead of other property-related tools (like 'anytype_update_property' or 'anytype_get_property'), or what context requires property creation. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action ('Elimina') without disclosing behavioral traits like whether deletion is permanent, requires specific permissions, affects related objects, or has side effects (e.g., data loss). For a destructive operation with zero annotation coverage, this is a critical gap.
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 a single, efficient sentence ('Elimina una propiedad') with zero wasted words. It is appropriately sized for a simple action, though its brevity contributes to gaps in other dimensions. No structural issues are present.
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?
Given the tool's complexity (a destructive operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address key aspects like return values, error conditions, or safety considerations, leaving significant gaps for an AI agent to understand the tool's behavior.
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 input schema has 100% description coverage, with clear parameter descriptions ('ID del espacio', 'ID de la propiedad'). The tool description adds no additional meaning beyond the schema, such as explaining what a 'property' entails or format examples. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Elimina una propiedad' (Deletes a property) states the basic action but is tautological with the tool name 'anytype_delete_property'. It doesn't specify what kind of property (e.g., object property, space property) or distinguish it from sibling tools like 'anytype_delete_object' or 'anytype_delete_tag'. The purpose is clear at a surface level but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With siblings like 'anytype_delete_object', 'anytype_delete_tag', and 'anytype_delete_type', the description doesn't clarify the specific context for property deletion, such as prerequisites (e.g., property must exist) or exclusions (e.g., cannot delete system properties).
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 carries the full burden of behavioral disclosure. The description only states it 'gets' a property, implying a read operation, but doesn't disclose any behavioral traits such as permissions required, error conditions, rate limits, or what happens if the property doesn't exist. For a tool with zero annotation coverage, this minimal description leaves significant gaps in understanding how it behaves.
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 extremely concise - a single Spanish phrase that directly states the action. While it's front-loaded and wastes no words, it's arguably too brief and under-specified rather than appropriately sized for the tool's complexity. However, it earns points for zero redundancy and clear structure within its limited scope.
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?
Given the tool has no annotations, no output schema, and operates in a complex system with many sibling tools, the description is inadequate. It doesn't explain what a 'property' means in this context, what format the returned property data takes, or how this tool fits within the broader Anytype ecosystem. For a read operation in a system with multiple retrieval tools, more context is needed for the agent to use it effectively.
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?
Schema description coverage is 100%, with both parameters ('space_id' and 'property_id') clearly documented in the schema. The description adds no additional meaning about these parameters beyond what the schema already provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtiene una propiedad específica' (Gets a specific property) is a tautology that essentially restates the tool name 'anytype_get_property' in Spanish. It doesn't specify what kind of property (e.g., object property, space property) or provide any distinguishing context from sibling tools like 'anytype_get_object' or 'anytype_get_space'. The purpose is vague and lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 this tool versus alternatives. With sibling tools like 'anytype_get_object', 'anytype_get_space', and 'anytype_list_properties', there's no indication of when this specific property retrieval tool is appropriate or what distinguishes it from other get operations. No context or exclusions are mentioned.
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 carries the full burden of behavioral disclosure. While 'obtiene' implies a read operation, the description doesn't address important behavioral aspects like pagination behavior (though offset/limit parameters suggest pagination), authentication requirements, rate limits, error conditions, or what format the returned objects will have. For a tool with 5 parameters and no output schema, this leaves significant gaps in understanding how the tool behaves.
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 a single, efficient sentence that states the core functionality. There's no wasted verbiage or unnecessary elaboration. However, it could be slightly more front-loaded with key differentiators if they existed. The structure is appropriate for the complexity level.
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?
Given the tool has 5 parameters, no annotations, no output schema, and multiple sibling tools with similar functionality, the description is insufficiently complete. It doesn't explain the relationship between space, list, and view IDs, doesn't describe the return format, doesn't differentiate from similar tools, and provides no behavioral context beyond the basic read operation. For a tool of this complexity, more comprehensive guidance is needed.
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?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal value beyond the schema - it mentions 'lista' (list) and 'vista específica' (specific view) which correspond to list_id and view_id parameters, but doesn't provide additional context about what these IDs represent or how to obtain them. With complete schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtiene objetos de una lista usando una vista específica' clearly states the action (obtiene/gets) and resource (objetos de una lista/objects from a list) with the specific mechanism (usando una vista específica/using a specific view). However, it doesn't distinguish this tool from sibling tools like 'anytype_list_objects' or 'anytype_search_objects', which appear to have overlapping functionality for listing objects. The purpose is clear but lacks sibling differentiation.
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 this tool versus alternatives. There are multiple sibling tools for listing/searching objects (anytype_list_objects, anytype_search_objects, anytype_get_object), but the description doesn't explain how this tool differs or when it should be preferred. No context, prerequisites, or exclusions are mentioned.
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 carries the full burden of behavioral disclosure. It states it 'obtiene' (gets/retrieves), implying a read-only operation, but doesn't specify if it requires authentication, returns detailed or summary data, handles errors, or has rate limits. For a tool with no annotations, this leaves critical behavioral traits undocumented.
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 a single, efficient sentence ('Obtiene un miembro específico') that directly states the purpose without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be more informative without sacrificing conciseness.
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?
Given the complexity (a retrieval tool with no output schema and no annotations), the description is incomplete. It doesn't explain what a 'member' is, what data is returned, or any behavioral context. With no output schema to clarify return values and no annotations for safety or behavior, the description fails to provide sufficient context for effective use.
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 input schema has 100% description coverage, with clear descriptions for 'space_id' and 'member_id'. The description adds no parameter-specific information beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline score is 3, as the schema adequately documents parameters without needing extra detail in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtiene un miembro específico' (Gets a specific member) states the verb ('obtiene') and resource ('miembro'), but it's vague about what a 'member' represents in this context. It doesn't distinguish from sibling tools like 'anytype_list_members' or 'anytype_get_space', leaving ambiguity about the scope and nature of the resource.
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. It doesn't mention prerequisites (e.g., needing a space_id and member_id), nor does it differentiate from 'anytype_list_members' for listing all members or other 'get_' tools for different resources. Usage is implied only by the name and description.
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 carries full burden. It only states it 'gets' a type, implying a read operation, but doesn't disclose behavioral traits such as error handling, permissions required, rate limits, or what happens if the type doesn't exist. This leaves significant gaps for safe invocation.
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 a single, efficient sentence in Spanish ('Obtiene un tipo específico'), which is appropriately concise and front-loaded. However, it's under-specified rather than truly concise, as it lacks necessary detail for clarity.
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?
Given no annotations, no output schema, and a vague description, this is incomplete for a tool with 2 required parameters. The description doesn't explain what a 'type' is, what data is returned, or how it differs from similar tools, making it inadequate for reliable agent use.
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?
Schema description coverage is 100%, with both parameters ('space_id' and 'type_id') documented in the schema. The description adds no additional meaning beyond the schema, such as explaining relationships between spaces and types or format examples. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtiene un tipo específico' (Gets a specific type) states a vague purpose with a verb+resource but lacks specificity about what 'type' means in this context. It doesn't distinguish from sibling tools like 'anytype_get_object' or 'anytype_get_property', leaving ambiguity about what resource is being retrieved.
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. With siblings like 'anytype_list_types' (for listing types) and 'anytype_get_object' (for retrieving objects), the description offers no context, prerequisites, or exclusions to help an agent choose appropriately.
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 carries the full burden of behavioral disclosure. It states it's an update operation, implying mutation, but doesn't disclose permissions required, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence ('Actualiza un espacio existente') that is front-loaded and wastes no words. It could be slightly more informative, but it's appropriately sized for a basic tool description.
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?
Given the tool's complexity (4 parameters, nested objects, mutation operation) and lack of annotations and output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances. For an update tool with no structured safety or output info, more context is needed.
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?
Schema description coverage is 100%, with each parameter documented in the schema (e.g., 'space_id' as ID, 'name' as new name). The description adds no additional meaning beyond the schema, such as format details or constraints. With high schema coverage, the baseline is 3, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Actualiza un espacio existente' (Updates an existing space) states a clear verb ('actualiza') and resource ('espacio'), but it's vague about what specific aspects are updated. It doesn't differentiate from sibling tools like 'anytype_update_object' or 'anytype_update_type', which also update resources. The purpose is understandable but lacks specificity.
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 this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing space ID), exclusions, or compare to siblings like 'anytype_create_space' for creation or 'anytype_get_space' for retrieval. Usage is implied by the verb 'update', but explicit context is missing.
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 provided, the description carries full burden but only states it's an update operation. It doesn't disclose behavioral traits like required permissions, whether changes are reversible, side effects on dependent objects, rate limits, or error conditions. For a mutation tool with 7 parameters, this is a significant gap in transparency.
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 extremely concise - a single Spanish phrase that directly states the action. While perhaps too brief for clarity, it's front-loaded with the core purpose and contains no redundant information. The efficiency is good, though it may sacrifice completeness.
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?
For a mutation tool with 7 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'tipo' means in this system, what happens when updating, what the response contains, or how this differs from other update operations. The context signals indicate significant complexity that the description doesn't address.
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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds no additional meaning beyond what's in the schema (like explaining relationships between parameters or special constraints). Baseline 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Actualiza un tipo existente' (Updates an existing type) states the basic action and resource but is vague about what 'tipo' (type) means in this context. It doesn't differentiate from sibling tools like 'anytype_update_object' or 'anytype_update_property', leaving ambiguity about what specific resource is being updated.
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 like 'anytype_update_object' or 'anytype_create_type'. The description doesn't mention prerequisites, exclusions, or appropriate contexts, leaving the agent to infer usage from the tool name alone.
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 carries the full burden. It states this is a creation operation, implying mutation, but doesn't disclose behavioral traits like permissions needed, whether the creation is reversible, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence in Spanish ('Crea un nuevo tipo de objeto') that directly states the purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste.
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?
Given this is a mutation tool (create) with 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address key contextual aspects like what the tool returns, error conditions, or how it integrates with the broader system (e.g., relation to sibling tools). The high parameter count and mutation nature demand more guidance than provided.
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?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no additional meaning about parameters beyond what's in the schema (e.g., it doesn't explain relationships between parameters like 'key' and 'name', or provide examples). Baseline 3 is appropriate 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.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Crea un nuevo tipo de objeto' clearly states the action (create) and resource (object type), which is adequate. However, it doesn't differentiate this from sibling tools like 'anytype_create_object' or 'anytype_create_property', leaving ambiguity about what specifically distinguishes an 'object type' from other creatable entities in the system.
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 this tool versus alternatives. With multiple 'create' siblings (object, property, space, tag, type), there's no indication of the specific context or prerequisites for creating an object type, such as whether it requires an existing space or how it relates to other entities.
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 carries full burden. It states 'Gets' implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what 'gets' entails (e.g., returns tag metadata). For a tool with no annotations, this is insufficient.
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 extremely concise with a single sentence 'Gets a specific tag', which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration.
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?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what 'gets' returns (e.g., tag details), error conditions, or how it differs from sibling tools. For a basic retrieval tool, more context is needed to be fully helpful.
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?
Schema description coverage is 100%, with both parameters ('space_id' and 'tag_id') documented in the schema. The description adds no meaning beyond the schema, as it doesn't explain parameter relationships or usage. Baseline 3 is appropriate since the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets a specific tag' clearly states the action (get) and resource (tag), but it's vague about scope and doesn't differentiate from sibling tools like 'anytype_get_object' or 'anytype_list_tags'. It lacks specificity about what 'specific' means (e.g., by ID vs. name).
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 like 'anytype_list_tags' for listing all tags or other 'get_' tools for different resources. The description implies retrieval by ID but doesn't explicitly state prerequisites or exclusions.
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 provided, the description carries the full burden of behavioral disclosure. It states 'Gets,' implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns structured data, or handles errors. This is a significant gap for a tool with no annotation coverage.
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 extremely concise with a single sentence, 'Gets a specific template,' which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration, earning full marks for brevity and clarity.
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?
Given the complexity (3 required parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what a 'template' is in this context, how the output might be structured, or any behavioral aspects like error handling. This leaves the agent under-informed for proper tool invocation.
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 input schema has 100% description coverage, clearly documenting all three required parameters (space_id, type_id, template_id). The description adds no additional semantic context beyond the schema, such as explaining relationships between parameters. Baseline 3 is appropriate 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.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets a specific template' clearly states the action (get) and resource (template), which is better than a tautology. However, it lacks specificity about what 'specific' means (e.g., by ID) and doesn't differentiate from sibling tools like 'anytype_list_templates' or 'anytype_get_object', leaving room for ambiguity.
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. For example, it doesn't clarify if this is for retrieving a single template by ID versus listing all templates, nor does it mention prerequisites like needing space and type IDs. This leaves the agent without context for tool selection.
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 carries full burden. It states it's a listing operation, which implies read-only behavior, but doesn't disclose any behavioral traits like pagination, rate limits, authentication needs, or what 'todos' (all) entails in practice. Minimal value beyond the obvious.
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?
Extremely concise with a single sentence that directly states the purpose. No wasted words, though this brevity contributes to gaps in other dimensions. It's front-loaded and efficient.
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?
Given no annotations, no output schema, and a simple parameter, the description is incomplete. It doesn't explain what 'tipos de objetos' means in this context, how results are returned, or any limitations. For a listing tool in a system with many sibling tools, more context is needed.
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?
Schema description coverage is 100%, with the single parameter 'space_id' fully documented in the schema. The description adds no additional meaning about parameters beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista todos los tipos de objetos' clearly states the action (list) and resource (object types), but it's vague about scope and doesn't distinguish from sibling tools like 'anytype_get_type' or 'anytype_list_objects'. It's a basic translation of the tool name without additional context.
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 like 'anytype_get_type' (for a single type) or 'anytype_list_objects' (for objects, not types). The description implies a comprehensive listing but doesn't specify context or exclusions.
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 carries full burden but provides minimal behavioral insight. It states the action is an 'add' operation, implying mutation, but doesn't disclose permissions needed, side effects (e.g., if duplicates are allowed), error conditions, or response format. This leaves critical behavioral traits unaddressed for a mutation tool.
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 a single, direct sentence with no wasted words. It front-loads the core purpose efficiently, making it easy to parse and understand at a glance.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., idempotency, errors), expected outcomes, or how it fits into the broader toolset. Given the complexity implied by sibling tools, more context is needed for effective use.
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?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds no additional meaning about parameters beyond implying they identify the object and collection. Since the schema already documents all parameters adequately, the baseline score of 3 is appropriate.
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 ('Adds') and the target resources ('an object to a collection'), which is specific and unambiguous. However, it doesn't differentiate from its sibling 'anytype_remove_from_collection' beyond the opposite action, nor does it explain what a 'collection' is in this context relative to other tools like 'anytype_list_objects'.
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. It doesn't mention prerequisites (e.g., needing existing objects/collections), compare to similar tools like 'anytype_update_object', or indicate scenarios where adding to a collection is appropriate versus other operations.
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 provided, the description carries full burden for behavioral disclosure. While 'Crea un nuevo objeto' implies a write/mutation operation, the description doesn't mention required permissions, whether this operation is idempotent, what happens on conflicts, or what the response contains. For a creation tool with complex parameters and no annotation coverage, this is insufficient.
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 a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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?
For a creation tool with 8 parameters (including complex nested objects), no annotations, and no output schema, the description is inadequate. It doesn't explain what an 'object' represents in this context, what happens after creation, error conditions, or how this differs from similar tools. The single sentence leaves too many contextual gaps.
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?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 ('Crea un nuevo objeto') and target resource ('en un espacio'), which is a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'anytype_update_object' or explain what differentiates creating an object from other creation tools like 'anytype_create_space' or 'anytype_create_tag'.
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 this tool versus alternatives. With multiple sibling tools including 'anytype_update_object', 'anytype_get_object', and various other creation tools, there's no indication of when creation is appropriate versus updating, retrieving, or using other object-related operations.
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 carries the full burden. 'Crea' implies a write operation, but it doesn't disclose behavioral traits such as permissions required, whether the creation is irreversible, rate limits, or what happens on success/failure. This is a significant gap for a mutation tool with zero annotation coverage.
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 a single, efficient sentence with zero waste. It is front-loaded and appropriately sized for its purpose, making it easy to parse without unnecessary elaboration.
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?
Given the complexity of a creation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects, usage context, and expected outcomes, which are critical for an agent to invoke this tool correctly in a system with multiple sibling tools.
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?
Schema description coverage is 100%, with clear descriptions for name, description, and icon parameters. The description adds no additional meaning beyond the schema, such as format details or constraints. Baseline 3 is appropriate as the schema adequately documents parameters without extra value from the description.
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 'Crea un nuevo espacio' clearly states the verb ('crea') and resource ('espacio'), making the purpose evident. It distinguishes this as a creation tool among siblings that include update_space, get_space, and list_spaces. However, it doesn't specify what a 'space' is in this context, which slightly limits specificity.
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. With siblings like anytype_create_object and anytype_update_space, the description lacks context on prerequisites, appropriate scenarios, or exclusions, leaving the agent to infer usage from the tool name alone.
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 carries full burden for behavioral disclosure. 'Creates' implies a write operation, but the description doesn't specify required permissions, whether the operation is idempotent, what happens on duplicate names, or what the response looks like. This leaves significant behavioral gaps for a creation tool.
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 a single, efficient sentence with zero wasted words. It's appropriately sized for a simple creation operation and front-loads the core purpose immediately.
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?
For a creation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what a successful creation returns, error conditions, or behavioral constraints. Given the complexity of creating a tag with multiple required parameters, more context is needed for the agent to use this tool effectively.
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?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no parameter information beyond what's in the schema (space_id, name, color, property_id). Baseline 3 is appropriate when the schema does all the parameter documentation work.
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 ('creates') and resource ('new tag'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'anytype_update_tag' or 'anytype_delete_tag', which would require mentioning it's specifically for initial creation rather than modification or removal.
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 this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing space), when not to use it (e.g., for updating existing tags), or refer to sibling tools like 'anytype_update_tag' for modifications.
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 carries the full burden of behavioral disclosure. 'Elimina (archiva) un objeto' indicates a destructive mutation (delete/archive), but it doesn't clarify if deletion is permanent, reversible, or requires specific permissions. It also omits details like rate limits, error conditions, or what 'archiva' entails versus deletion. For a mutation tool with zero annotation coverage, this is a significant gap.
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 extremely concise—a single phrase in Spanish—with zero wasted words. It front-loads the key action ('Elimina') and target ('objeto'), making it easy to scan. Every word earns its place by conveying the core purpose efficiently.
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?
Given the tool's complexity (destructive mutation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like safety, permissions, or return values, which are critical for a delete operation. While concise, it fails to provide enough context for safe and effective use by an AI agent.
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 input schema has 100% description coverage, with clear parameter descriptions ('ID del espacio', 'ID del objeto'). The tool description adds no parameter-specific information beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline is 3, as the schema adequately documents parameters without extra help from the description.
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 'Elimina (archiva) un objeto' clearly states the action (delete/archive) and target (object) in Spanish, making the purpose understandable. It distinguishes from siblings like 'anytype_update_object' or 'anytype_get_object' by specifying deletion rather than modification or retrieval. However, it doesn't explicitly differentiate from 'anytype_delete_property', 'anytype_delete_tag', or 'anytype_delete_type', which target different resources.
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 this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing object), exclusions (e.g., not for collections or other resources), or comparisons to siblings like 'anytype_remove_from_collection' for similar actions. Usage is implied only by the name and action, with no explicit 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?
No annotations are provided, so the description carries full burden. It states 'Deletes a tag', implying a destructive mutation, but doesn't disclose behavioral traits such as permissions required, whether deletion is permanent or reversible, side effects (e.g., on objects using the tag), or error handling. This leaves critical gaps for a destructive 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?
The description is a single sentence 'Deletes a tag', which is extremely concise and front-loaded with the core action. There is no wasted text or redundancy, making it efficient for quick understanding, though it may be overly brief for completeness.
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?
Given the complexity (a destructive mutation tool with no annotations and no output schema), the description is incomplete. It lacks details on behavior, outcomes, error cases, and context needed for safe invocation. While the schema covers parameters well, the overall tool understanding is inadequate for a deletion operation, risking misuse by an agent.
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%, with clear parameter descriptions ('Space ID' and 'Tag ID'), so the schema provides full parameter documentation. The description adds no parameter semantics beyond the schema, but with 0 parameters explicitly mentioned in the description and high schema coverage, the baseline is 3. It earns a 4 because the description is concise and doesn't mislead, though it doesn't compensate for any gaps (there are none).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deletes a tag' states the basic action (delete) and resource (tag), which is clear but minimal. It distinguishes from siblings like 'anytype_get_tag' or 'anytype_update_tag' by the verb, but doesn't specify scope or constraints beyond the name. It's not tautological but lacks specificity about what a 'tag' means in this context.
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. It doesn't mention prerequisites (e.g., needing a tag to exist), exclusions, or related tools like 'anytype_delete_object' for comparison. The agent must infer usage from the name alone, which is insufficient for informed selection.
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 carries the full burden of behavioral disclosure. 'Elimina' implies a destructive mutation, but it doesn't specify permissions required, whether deletion is reversible, what happens to dependent objects, or error handling. For a deletion tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste.
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?
Given the tool's complexity as a deletion operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like side effects, return values, or error conditions, which are crucial for safe tool invocation in a multi-tool environment.
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?
Schema description coverage is 100%, with both parameters ('space_id' and 'type_id') clearly documented in the schema. The description adds no additional meaning beyond what the schema provides, such as explaining relationships between spaces and types. Baseline 3 is appropriate 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Elimina un tipo de objeto' clearly states the action (eliminates/deletes) and the resource (object type) in Spanish. It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'anytype_delete_object' or 'anytype_delete_tag', which lowers it from a perfect score.
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 this tool versus alternatives. With siblings like 'anytype_delete_object' and 'anytype_delete_tag', it's unclear what distinguishes deleting a type from deleting other entities. No prerequisites, exclusions, or context are mentioned.
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 carries the full burden of behavioral disclosure. It states it 'gets' an object, implying a read operation, but doesn't clarify permissions required, whether it returns full object data or metadata, error conditions (e.g., invalid IDs), or response format. For a read tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that directly states the tool's action without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose ('Obtiene un objeto específico'). Every part of the sentence contributes to understanding the tool's function.
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?
Given the tool's complexity (simple retrieval but with required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'gets' entails (e.g., returns object properties, metadata), error handling, or how it differs from list/search siblings. For a tool in a rich sibling set with no structured output guidance, more context is needed.
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?
Schema description coverage is 100%, with both parameters ('space_id', 'object_id') clearly documented in the schema. The description adds no additional parameter semantics beyond implying 'object_id' identifies the specific object to retrieve. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with extra context like ID format examples.
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 verb ('obtiene' - gets) and resource ('un objeto específico' - a specific object), making the purpose understandable. It distinguishes from sibling tools like 'anytype_list_objects' by specifying retrieval of a single object by ID rather than listing multiple objects. However, it doesn't explicitly mention the 'space_id' context which is required, making it slightly less specific than ideal.
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 this tool versus alternatives like 'anytype_get_list_objects' or 'anytype_search_objects'. It doesn't mention prerequisites (e.g., needing to know both space and object IDs) or exclusions (e.g., not for bulk retrieval). Usage is implied through the action but lacks explicit contextual boundaries.
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 carries full burden. It states it lists members but doesn't disclose behavioral traits like pagination behavior (implied by limit/offset but not explained), whether it's read-only (implied by 'list' but not explicit), authentication needs, rate limits, or what the output looks like (no output schema). The description adds minimal context beyond the basic action.
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 a single, efficient sentence in Spanish ('Lista todos los miembros de un espacio') that directly states the purpose. It's front-loaded with no wasted words, making it easy to parse quickly. Every word earns its place by specifying the action and resource.
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?
Given no annotations and no output schema, the description is incomplete for a tool with 3 parameters. It doesn't explain the return format, error conditions, or behavioral nuances like pagination. For a list operation in a system with many sibling tools, more context is needed to ensure correct usage, especially since it's a read operation that might have constraints not covered.
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?
Schema description coverage is 100%, so the schema already documents all parameters (space_id, limit, offset) with descriptions. The description doesn't add any meaning beyond what the schema provides, such as explaining how space_id is obtained or the implications of limit/offset values. Baseline 3 is appropriate as the schema does the heavy lifting.
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 'Lista todos los miembros de un espacio' clearly states the action (list) and resource (members of a space). It distinguishes from siblings like anytype_get_member (singular) and anytype_list_objects/properties/spaces (different resources). However, it doesn't specify the scope (e.g., all members vs. filtered) or differentiate from other list tools beyond the resource name.
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 doesn't mention prerequisites (e.g., needing space_id), when not to use it, or how it compares to siblings like anytype_get_member or anytype_search_objects for member-related queries. The description only states what it does, not when it's appropriate.
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 provided, the description carries full burden for behavioral disclosure. It states it's a list operation but doesn't mention whether it's read-only, safe, paginated (beyond what the schema implies), rate-limited, or requires specific permissions. The description adds minimal behavioral context beyond the basic action.
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 a single, efficient Spanish sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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?
For a list operation with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'objetos' means in this context, what format the results take, whether there are ordering constraints, or how it differs from similar sibling tools. The description leaves too many contextual gaps.
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?
Schema description coverage is 100%, so the schema already documents all three parameters (space_id, limit, offset) with their types, descriptions, and defaults. The description mentions 'en un espacio específico' which aligns with the space_id parameter but adds no additional semantic context beyond what the schema provides.
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 'Lista objetos en un espacio específico' clearly states the verb ('Lista') and resource ('objetos') with scope ('en un espacio específico'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'anytype_get_list_objects' or 'anytype_search_objects', which appear to have overlapping functionality.
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 this tool versus alternatives like 'anytype_get_list_objects' or 'anytype_search_objects'. It mentions a specific space context but doesn't clarify prerequisites, exclusions, or comparative use cases with sibling tools.
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 provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this is a read-only operation, if it requires specific permissions, how pagination works beyond the schema, or what the output format looks like (e.g., list of property objects). This is inadequate for a tool with parameters and no output schema.
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 a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste.
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?
Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., read-only nature, pagination behavior) and doesn't explain what the output contains, which is critical for an agent to use it effectively. The schema covers parameters well, but other aspects are missing.
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 schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond implying a space context for 'space_id', which is already clear from the schema. This meets the baseline of 3 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista todas') and resource ('propiedades de un espacio'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'anytype_get_property' (singular vs. plural) or 'anytype_list_objects' (objects vs. properties), which would require a 5.
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 this tool versus alternatives. It doesn't mention sibling tools like 'anytype_get_property' for single properties or 'anytype_list_objects' for listing objects instead of properties, leaving the agent without context for selection.
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 provided, the description carries full burden but lacks behavioral details. It doesn't disclose whether this is a read-only operation, if it requires authentication, potential rate limits, pagination behavior (implied by parameters but not described), or what the output format looks like (no output schema). The description only states the basic action without operational 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?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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?
Given no annotations and no output schema, the description is incomplete for a tool with 4 parameters (including pagination). It doesn't explain the return values, error conditions, or behavioral traits like pagination handling. For a list operation with pagination parameters, more context is needed to guide effective use.
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?
Schema description coverage is 100%, so the schema fully documents all parameters (space_id, type_id, limit, offset). The description adds no additional meaning beyond implying templates are associated with types, which is already covered in the schema's type_id description. Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb ('Lists') and resource ('all available templates for a specific type'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'anytype_get_template' (singular) or 'anytype_list_types', which might list types rather than templates associated with types.
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 this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid space and type), exclusions, or compare it to siblings like 'anytype_get_template' (which might fetch a single template) or 'anytype_list_types' (which lists types, not templates).
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 provided, the description carries the full burden of behavioral disclosure. It states the action is a removal, implying a mutation, but doesn't specify if this is reversible, requires specific permissions, affects related data, or has side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, direct sentence with zero wasted words. It's front-loaded with the core action and target, making it highly efficient and easy to parse. Every word earns its place by conveying essential information.
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?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, error conditions, return values, and usage context. While concise, it doesn't provide enough information for safe and effective use by an AI agent.
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 schema description coverage is 100%, with clear descriptions for each parameter (space_id, collection_id, object_id). The description doesn't add any meaning beyond this, such as explaining relationships between parameters or providing examples. Baseline 3 is appropriate when the schema fully documents parameters.
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 ('removes') and the target ('an object from a collection'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'anytype_delete_object' or 'anytype_delete_collection' (if such existed), leaving some ambiguity about scope and alternatives.
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 this tool versus alternatives. It doesn't mention prerequisites (e.g., needing the object to be in the collection first), exclusions, or compare it to siblings like 'anytype_delete_object' for more permanent removal. This leaves the agent without context for tool selection.
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 carries the full burden of behavioral disclosure. 'Updates an existing tag' implies a mutation operation, but it doesn't specify permissions required, whether changes are reversible, error handling, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 a single sentence, 'Updates an existing tag', which is extremely concise and front-loaded with the core action. There is zero waste or redundancy, making it efficiently structured for quick understanding.
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?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., side effects, permissions), output format, or error handling. For a tool with 4 parameters and potential complexity in updating tags, more context is needed to be fully helpful.
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?
Schema description coverage is 100%, so the schema already documents all parameters (space_id, tag_id, name, color) with descriptions and an enum for color. The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 'Updates an existing tag' clearly states the action (update) and resource (tag), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'anytype_update_object' or 'anytype_update_property' beyond the resource name, missing explicit distinction in scope or function.
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 this tool versus alternatives like 'anytype_create_tag' or 'anytype_delete_tag', nor does it mention prerequisites or context. It lacks explicit when/when-not instructions or named alternatives, leaving usage unclear.
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 carries the full burden of behavioral disclosure. It states it 'gets' views, implying a read-only operation, but doesn't specify permissions, rate limits, or what 'available views' entails (e.g., format, pagination). For a tool with zero annotation coverage, this is insufficient, though it at least hints at a retrieval function.
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 a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 moderate complexity (2 required parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, or sibling differentiation. Without annotations or output schema, more context would be helpful, but it's not completely inadequate.
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 input schema has 100% description coverage, with clear parameter definitions ('space_id' and 'list_id'), so the schema does the heavy lifting. The description doesn't add any meaning beyond what's in the schema, such as explaining relationships between parameters or usage nuances. Baseline 3 is appropriate when schema coverage is high.
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 'Obtiene las vistas disponibles para una lista' clearly states the action ('obtiene' - gets/retrieves) and resource ('vistas disponibles para una lista' - available views for a list), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'anytype_get_list_objects' or 'anytype_get_object', which might also retrieve list-related information, so it falls short of a perfect score.
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 this tool versus alternatives. With siblings like 'anytype_get_list_objects' and 'anytype_get_object' that might retrieve similar or related data, there's no indication of context, prerequisites, or exclusions. This leaves the agent without clear usage instructions.
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 provided, the description carries the full burden of behavioral disclosure. While 'obtiene' implies a read operation, it doesn't specify whether this requires authentication, what happens if the space doesn't exist (error behavior), or what format the returned data takes. For a retrieval tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 a single, efficient Spanish sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple retrieval operation and front-loads the essential information.
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 single-parameter retrieval tool with good schema coverage but no annotations and no output schema, the description is minimally adequate. It states what the tool does but lacks important context about authentication requirements, error handling, and return format that would help an agent use it correctly.
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 input schema has 100% description coverage, with the single parameter 'space_id' clearly documented as 'ID del espacio'. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline expectation when schema coverage is complete.
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 ('obtiene' - gets/retrieves) and the resource ('un espacio específico' - a specific space), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'anytype_get_object' or 'anytype_get_member' which suggests similar retrieval operations for different resource types.
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 this tool versus alternatives like 'anytype_list_spaces' for browsing spaces or 'anytype_get_object' for retrieving other resources. There's no mention of prerequisites, context requirements, or typical use cases for retrieving a specific space by ID.
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 provided, the description carries the full burden of behavioral disclosure. It states this is a list operation, implying it's likely read-only and non-destructive, but doesn't explicitly confirm this. It doesn't describe the return format (e.g., list of tag objects), pagination behavior (implied by limit/offset parameters but not explained), error conditions, or any rate limits. The description adds minimal behavioral context beyond the basic action.
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 a single, efficient sentence that states the core functionality without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse. There's zero waste or redundancy in the phrasing.
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 moderate complexity (listing with pagination), no annotations, and no output schema, the description is minimally adequate but has clear gaps. It covers the basic purpose but lacks behavioral details (e.g., return format, error handling) and usage guidance. For a list tool with pagination parameters, more context about the output structure would be helpful, though the schema covers inputs well.
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?
Schema description coverage is 100%, so the schema already documents all parameters (space_id, property_key, limit, offset) with descriptions. The description doesn't add any meaning beyond what the schema provides—it doesn't explain relationships between parameters (e.g., that tags are listed for a specific property within a space) or provide usage examples. Baseline 3 is appropriate 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists') and resource ('all tags for a property'), making the purpose immediately understandable. It distinguishes this tool from other list operations like 'anytype_list_objects' or 'anytype_list_properties' by specifying tags for properties. However, it doesn't explicitly differentiate from 'anytype_get_tag' which might retrieve a specific tag rather than listing all tags for a property.
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 this tool versus alternatives. It doesn't mention when to choose this over 'anytype_get_tag' (which might retrieve a single tag) or other list tools like 'anytype_list_objects'. There's also no information about prerequisites or context for using this tool, such as needing an existing property with tags.
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 carries full burden. It mentions searching across spaces but doesn't disclose behavioral traits like: whether this is a read-only operation, how results are returned (format, pagination), performance characteristics, authentication requirements, or error conditions. For a search tool with 4 parameters and no annotations, this is a significant gap in 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?
The description is a single, efficient sentence in Spanish that clearly states the core functionality. It's appropriately sized for a search tool and front-loads the essential information without unnecessary elaboration. Every word earns its place.
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 4 parameters with 100% schema coverage but no annotations and no output schema, the description is minimally adequate. It covers the basic purpose but lacks important context about behavioral traits, result format, and differentiation from sibling tools. For a search operation that likely returns complex results, more guidance would be helpful despite the good parameter documentation.
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?
Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description adds minimal value beyond the schema - it implies the 'space_id' parameter allows searching in specific spaces versus all spaces, but doesn't provide additional context about parameter interactions, search syntax, or result ordering. Baseline 3 is appropriate 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Busca objetos en todos los espacios o en un espacio específico' (Search objects in all spaces or in a specific space). It specifies the verb 'busca' (search) and resource 'objetos' (objects), with scope clarification. However, it doesn't explicitly differentiate from sibling tools like 'anytype_get_list_objects' or 'anytype_list_objects', which appear to be similar listing operations.
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 this tool versus alternatives. It doesn't mention sibling tools like 'anytype_get_list_objects' or 'anytype_list_objects', nor does it explain when search functionality is preferred over simple listing. There's no context about prerequisites, constraints, or typical use cases.
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 provided, the description carries full burden for behavioral disclosure. It states it's a list operation but doesn't mention whether it's paginated, sorted, filtered, or what format the output takes. For a list tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 a single, efficient sentence in Spanish that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple list operation and front-loads the essential information.
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 list tool with no parameters and no output schema, the description is minimally adequate but lacks important context. It doesn't explain what information is returned about each space, whether there are access restrictions, or how the list is organized. The absence of annotations means the description should do more to compensate.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist, which is correct for this case. Baseline for 0 params is 4.
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 verb ('Lista' - List) and resource ('todos los espacios disponibles' - all available spaces), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'anytype_get_space' or 'anytype_list_objects', which would require more specificity for a perfect score.
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 this tool versus alternatives like 'anytype_get_space' (for a specific space) or 'anytype_list_objects' (for objects within spaces). There's no mention of prerequisites, context, or comparison with sibling tools.
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 provided, the description carries full burden and delivers crucial behavioral information. It discloses the non-standard 'replacement strategy' behavior where content updates create a new object and delete the original, explaining this is due to API limitations with markdown. This goes beyond basic 'update' semantics to reveal important implementation details an agent needs to know.
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 perfectly concise with two sentences that each earn their place. The first states the core purpose, the second provides critical behavioral guidance with the 'IMPORTANTE' flag front-loading the most crucial information. There's zero wasted text or redundancy.
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 mutation tool with no annotations and no output schema, the description does an excellent job covering the most critical behavioral aspects (the replacement strategy). However, it doesn't address other important context like permission requirements, error conditions, or what the tool returns. Given the complexity of the input schema (7 parameters with nested objects), some additional guidance about the update operation's scope would be beneficial.
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?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds minimal parameter-specific information beyond noting the replacement strategy applies to body/markdown parameters. It doesn't explain parameter interactions or provide additional context about the complex 'properties' array structure, so it meets but doesn't exceed the baseline expectation.
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 verb ('Actualiza' - updates) and resource ('un objeto existente' - an existing object), making the purpose evident. It distinguishes from creation tools like 'anytype_create_object' by specifying it's for existing objects. However, it doesn't explicitly differentiate from other update tools like 'anytype_update_property' or 'anytype_update_space' beyond the object focus.
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 provides explicit usage guidance with the 'IMPORTANTE' section that specifies when to use this tool for content updates (body/markdown) versus when not to use traditional update methods. It clearly states the replacement strategy is required for markdown content due to API limitations, giving specific context for when this tool is appropriate.
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/cryptonahue/mcp-anytype'
If you have feedback or need assistance with the MCP directory API, please join our Discord server