Anytype MCP Server

by Qwinty

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between get_objects, search_space, and global_search, which all involve searching or retrieving objects, potentially causing confusion. However, their descriptions clarify the scope differences (space-specific vs. global, with filters), so agents can differentiate with careful reading.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as create_object, get_objects, delete_object, and export_object. There are no deviations in naming conventions, making the set predictable and easy to understand.
Tool Count4/5
With 18 tools, the count is slightly high but reasonable for a comprehensive Anytype server covering spaces, objects, lists, templates, types, and members. It supports core workflows without being overly bloated, though it might feel dense for simpler use cases.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for the Anytype domain, including create, read, update (implied via object modifications), delete, export, search, and management of spaces, lists, templates, types, and members. There are no obvious gaps that would hinder agent operations.
Average 3.7/5 across 18 of 18 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention permissions needed, rate limits, whether duplicates are allowed, or what happens if objects are already in the list, leaving critical operational details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 fails to explain what the tool returns, error conditions, or side effects, leaving significant gaps in understanding how to use it effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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. The description adds no additional meaning beyond implying that 'object_ids' are added to a list, which is redundant with the schema. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds') and target ('objects to a specific list in a space'), making the purpose understandable. It distinguishes from siblings like 'remove_object_from_list' by specifying addition rather than removal, though it doesn't explicitly contrast with other list-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 'create_object' or 'remove_object_from_list'. The description lacks context about prerequisites, such as whether objects must already exist or be in the same space, 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 'retrieves' which implies a read-only operation, but doesn't clarify permissions, rate limits, pagination behavior beyond the schema, or what happens with invalid inputs. For a tool with 5 parameters and no annotations, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('retrieves objects') and adds necessary qualifiers ('from a specific list view with applied filters and sorting'). There is zero waste, and it's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 5 parameters. It doesn't explain the return format, error conditions, or behavioral nuances like how filters/sorting are applied. For a retrieval tool in a context with many siblings, more guidance is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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, list_id, view_id, offset, limit). The description adds minimal value by mentioning 'filters and sorting' but doesn't explain how these relate to the parameters or provide additional context beyond the schema. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieves' and the resource 'objects from a specific list view', making the purpose understandable. It specifies that filters and sorting are applied, which distinguishes it from generic retrieval tools like 'get_objects'. However, it doesn't explicitly differentiate from 'get_list_views' (which likely retrieves views rather than objects), leaving some sibling distinction incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 list view setup), exclusions, or compare it to sibling tools like 'get_objects' (which might retrieve objects without view filters) or 'global_search'. Usage is implied by the name but not explicitly stated.
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 mentions the search scope and filtering/sorting options but lacks critical behavioral information: it doesn't mention pagination behavior (though offset/limit parameters exist), rate limits, authentication requirements, performance characteristics, or what happens when no results are found. The description is insufficient for a tool with 7 parameters and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality. It's appropriately sized for the tool's complexity and gets straight to the point without unnecessary verbiage. However, it could be more front-loaded with critical behavioral information given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns (objects, metadata, content snippets), how results are structured, or important behavioral aspects like pagination, rate limits, or error conditions. The mention of 'include_text' parameter with 'USE WITH CAUTION' in the schema suggests performance implications that should be addressed in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'filtering by type and sorting' which corresponds to the 'types', 'sort_property', and 'sort_direction' parameters. However, with 100% schema description coverage, all parameters are already documented in the schema. The description adds minimal value beyond what's in the structured schema - it doesn't explain parameter interactions, provide examples, or clarify edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Executes a search across all spaces the user has access to, with options for filtering by type and sorting.' It specifies the verb ('executes a search'), resource ('all spaces the user has access to'), and scope ('filtering by type and sorting'). However, it doesn't explicitly differentiate from its sibling 'search_space', which appears to be a more targeted search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 the sibling tool 'search_space' or explain when a global search is preferred over a space-specific search. There's no discussion of prerequisites, performance considerations, or use case scenarios.
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 the action is 'removes,' implying a destructive mutation, but doesn't disclose behavioral traits like whether removal is permanent/reversible, permission requirements, error conditions (e.g., if object isn't in list), or what happens to the object after removal (e.g., deleted or just unlinked). This leaves significant gaps 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and target, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks crucial context like what 'removes' entails (e.g., permanent deletion or unlisting), expected outcomes, error handling, or permissions. Given the complexity and missing structured data, it should provide more behavioral guidance to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all three parameters (space_id, list_id, object_id). The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or providing examples. Baseline 3 is appropriate since 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('removes') and target ('an object from a specific list in a space'), making the purpose understandable. It distinguishes from obvious siblings like 'add_objects_to_list' by specifying removal rather than addition. However, it doesn't differentiate from 'delete_object' which might delete the object entirely rather than just removing it from a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 list first), when not to use it (e.g., vs. deleting the object entirely), or refer to sibling tools like 'delete_object' or 'add_objects_to_list' for 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 the full burden of behavioral disclosure. It mentions 'options for filtering by type and sorting' but lacks critical details: it doesn't specify what types of objects are searchable, the search scope (e.g., metadata, content), pagination behavior (implied by offset/limit but not explained), performance implications, or error handling. For a search tool with 9 parameters and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and waste, though it could be slightly more structured (e.g., separating scope from options). It earns its place by summarizing key capabilities concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, search functionality), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns (e.g., object metadata, snippets), how results are formatted, or limitations (e.g., search accuracy, rate limits). For a search tool, this leaves significant gaps for an AI agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are documented in the schema. The description adds minimal value beyond the schema—it mentions 'filtering by type and sorting,' which aligns with the 'types,' 'sort_property,' and 'sort_direction' parameters but doesn't provide additional context like valid type values or sorting nuances. With high schema coverage, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Executes a search within a specific space, with options for filtering by type and sorting.' It specifies the verb ('executes a search'), resource ('within a specific space'), and scope ('filtering by type and sorting'). However, it doesn't explicitly differentiate from sibling tools like 'global_search' or 'get_objects', 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/5
Does 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 'global_search' (for searches across all spaces) or 'get_objects' (for retrieving objects without search), nor does it specify prerequisites or exclusions. The agent must infer usage from the description 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions retrieval but doesn't specify whether this is a read-only operation, if it requires specific permissions, what the return format looks like, or any rate limits. For a tool with 4 parameters and no 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/5
Is 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 adds valuable context about what views define. No wasted words, and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with 4 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate basic purpose but lacks important behavioral context. It doesn't explain what the return values look like or any operational constraints, leaving the agent with incomplete understanding despite good schema documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 thoroughly. The description adds no additional parameter information beyond what's in the schema descriptions. This meets the baseline of 3 when schema coverage is high, but doesn't provide extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('views configured for a specific list in a space'), with additional context about what views define. It distinguishes from siblings like get_objects or get_list_view_objects by focusing on view configurations rather than objects themselves. However, it doesn't explicitly differentiate from all possible siblings in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing view configurations for a list, but provides no explicit guidance on when to use this versus alternatives like get_list_view_objects (which retrieves objects within a view) or other list-related tools. No exclusions or prerequisites are mentioned, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal pagination behavior ('Results are paginated for better performance with large spaces') and mentions the include_text parameter's effect on content retrieval. However, it doesn't disclose important behavioral aspects like whether this is a read-only operation (implied but not stated), performance characteristics, error conditions, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized at 4 sentences and front-loaded with the core purpose. However, the third sentence ('Use this tool to...') is somewhat redundant with the first two sentences, and the final sentence about include_text could be integrated more efficiently. Most sentences earn their place but could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search/retrieval tool with 5 parameters, 100% schema coverage, but no annotations and no output schema, the description is adequate but has clear gaps. It covers the basic purpose and some behavioral aspects (pagination, include_text) but lacks information about return values, error handling, performance considerations, and explicit differentiation from similar search tools. The absence of an output schema increases the need for return value description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 5 parameters thoroughly. The description adds minimal value beyond the schema - it only mentions the include_text parameter's purpose ('allows retrieving the full formatted text content of objects'), which is already covered in the schema description. No additional syntax, format details, or parameter relationships are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as searching for and retrieving objects within a specified Anytype space, with specific verbs ('searches for', 'retrieves', 'list', 'filter', 'discover', 'find', 'browse'). It distinguishes from some siblings like create_object or delete_object but doesn't explicitly differentiate from similar search tools like search_space or global_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance ('Use this tool to discover objects within a space, find specific objects by name, or browse through collections of objects') but doesn't explicitly state when to use this tool versus alternatives like search_space or global_search. It mentions pagination for large spaces but lacks explicit when-not-to-use guidance or clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It correctly identifies this as a creation/mutation operation ('Creates a new object') and mentions it works 'within a specified Anytype space.' However, it lacks important behavioral details like required permissions, whether the operation is idempotent, error conditions, or what happens on success. The mention of templates adds some context but doesn't fully compensate for the annotation gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences. It's front-loaded with the core purpose, followed by parameter context, and ends with usage guidance. There's minimal redundancy, though the second sentence could be slightly more concise by combining the parameter listing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 8 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the basic purpose, some parameters, and usage context, but lacks details about behavioral traits, error handling, and return values that would be important for a creation operation. The high schema coverage helps but doesn't fully compensate for the missing behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description mentions some parameters ('name, type, description, icon, and content') and adds context about templates, but doesn't provide significant additional semantic meaning beyond what's in the schema. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Creates a new object within a specified Anytype space' with specific resources (pages, notes, tasks) and context (within a space). It distinguishes from siblings like 'create_space' by focusing on objects rather than spaces, but doesn't explicitly differentiate from 'add_objects_to_list' which might 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'Use this tool when you need to add new content to an existing space.' This gives a positive when-to-use guideline. However, it doesn't explicitly mention when NOT to use it or name alternatives like 'add_objects_to_list' for list-specific operations or 'create_space' for space creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's behavior as exporting in Markdown format for external use or backup, which is helpful. However, it lacks details on permissions required, rate limits, file size constraints, or what happens if the object doesn't exist. The description adds some behavioral context but is incomplete for a mutation-like export operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences. The first sentence front-loads the core purpose, and subsequent sentences add useful context about Markdown format and usage scenarios. There is minimal redundancy, though the second sentence slightly rephrases the first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 provides adequate purpose and usage context but lacks details on behavioral aspects like error handling, output format specifics (e.g., file structure), or prerequisites. For an export tool with 3 parameters and no structured safety hints, it's minimally complete but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters (space_id, object_id, format). The description does not add any parameter-specific information beyond what the schema provides (e.g., it doesn't explain format constraints further). 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('exports'), resource ('Anytype object'), and format ('Markdown format'). It distinguishes this tool from siblings like 'get_object_content' (which presumably retrieves content without exporting) and 'delete_object' (which removes rather than exports). The purpose is unambiguous and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'when you need to share Anytype content with external systems or create portable backups.' It provides clear context for usage but does not specify when NOT to use it or name specific alternatives among the sibling tools (e.g., 'get_object_content' might be an alternative for internal viewing).
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 it states this is a creation operation, it doesn't mention important behavioral aspects like what permissions are required, whether there are limits on how many spaces can be created, what happens if a space with the same name exists, or what the response format looks like. For a creation tool with zero annotation coverage, this represents significant gaps in behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with two sentences that each serve distinct purposes: the first states what the tool does, and the second provides usage guidance. There's no redundant information or unnecessary elaboration, making it appropriately sized and front-loaded for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a creation tool with no annotations and no output schema, the description provides adequate basic information about purpose and usage but lacks important contextual details about behavioral aspects, error conditions, and response format. The description covers the minimum viable information but leaves significant gaps that an agent would need to understand fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'name' parameter. The description adds no additional parameter semantics beyond what's in the schema ('Name for the new space'). With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Creates a new Anytype space') and resource ('space'), distinguishing it from sibling tools like 'create_object' which creates objects within spaces rather than the space container itself. It explicitly mentions the purpose is to 'set up a fresh workspace for organizing objects and collaborating with others,' providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use this tool when you need to establish a new organizational container for your Anytype content.' This clearly distinguishes it from alternatives like 'create_object' (for creating content within spaces) or 'get_spaces' (for retrieving existing spaces), giving the agent clear 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what information is retrieved (type structure, relations, views, configuration options) which is helpful. However, it doesn't mention important behavioral aspects like whether this is a read-only operation (implied but not stated), potential rate limits, authentication requirements, or what happens if the type doesn't exist. The description adds value but leaves gaps in behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences. The first sentence states the core purpose, and the second provides usage guidance. Every element serves a clear purpose with no redundant information. It's appropriately sized and front-loaded with the main functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 2 parameters and 100% schema coverage but no annotations or output schema, the description provides adequate but not complete context. It explains what information is retrieved but doesn't describe the return format or structure. Given the complexity of retrieving 'comprehensive details' about object types, more information about the output would be helpful, but the description covers the essential purpose and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline of 3 when schema coverage is high, but doesn't provide additional semantic context about parameter usage or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('retrieves') and resource ('detailed information about a specific object type in an Anytype space'). It distinguishes from sibling tools like 'get_types' (which likely lists types) by specifying it provides comprehensive details about a particular type's structure including relations, views, and configuration options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'when you need to understand the structure of a particular object type or to examine its available relations and properties.' This provides clear context, though it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools (like 'get_types' for listing types rather than getting details).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as retrieving comprehensive details, which implies a read-only operation, but does not explicitly state behavioral traits like whether it requires specific permissions, rate limits, or error conditions. It adds some context about the type of information returned (structure, content, configuration), but lacks full behavioral disclosure for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: the first states the purpose, and the second provides usage guidelines. It is front-loaded with the core function and avoids unnecessary details, though it could be slightly more concise by combining ideas without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with 3 required parameters), no annotations, and no output schema, the description does a good job by explaining the purpose and usage. However, it lacks details on the return format or error handling, which would be helpful for completeness. It compensates somewhat with clear usage context but falls short of being fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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, type_id, template_id) with descriptions. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or interdependencies. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieves' and resource 'detailed information about a specific template in an Anytype space'. It distinguishes from sibling tools like 'get_templates' (which likely lists templates) by specifying retrieval of comprehensive details for a specific template, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'when you need to examine a template's properties before using it to create new objects, or to understand how a particular template is structured'. This provides clear context for usage, including a specific alternative scenario (using it to create objects) and distinguishes it from general listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the operation is permanent and irreversible ('deleted objects cannot be recovered'), destructive ('deletes the object and all its content'), and requires caution. It does not cover aspects like error handling, permissions, or rate limits, but provides sufficient critical information 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by critical warnings and a verification step. Each sentence adds value: the first defines the action, the second emphasizes permanence, the third advises caution, and the fourth specifies a prerequisite. There is no wasted text, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is largely complete. It covers the purpose, behavioral risks, and usage caution. It could improve by mentioning error cases (e.g., invalid IDs) or response format, but given the schema's full parameter coverage and the clear warning context, it provides sufficient guidance for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('space_id' and 'object_id'). The description adds no additional parameter-specific details beyond what the schema provides, such as format examples or constraints. The baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('permanently removes', 'deletes') and identifies the resource ('object from a specified Anytype space'). It distinguishes this destructive operation from sibling tools like 'remove_object_from_list' (which likely only removes from a list) and 'create_object'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage with warnings ('use with caution', 'verify before deletion') and implies this is for permanent removal versus alternatives like 'remove_object_from_list'. However, it does not explicitly name when to use this tool versus other deletion-related siblings or specify prerequisites beyond verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as a retrieval operation (implied read-only) and mentions comprehensive information, but lacks details on permissions, rate limits, error conditions, or response format. It adds some context about the include_text parameter's effect, but overall behavioral disclosure is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance and parameter clarification in two efficient sentences. Every sentence adds value without repetition or fluff, making it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given 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 does well by covering purpose, usage, and some parameter context. However, it lacks details on the return structure (e.g., what 'comprehensive information' includes) and error handling, which would be helpful for a retrieval tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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. The description adds minimal value by clarifying that include_text retrieves 'full formatted text content from blocks,' which slightly expands on the schema's description. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('detailed content and metadata for a specific object in an Anytype space'), specifying it provides comprehensive information including properties, relations, and content. It distinguishes from siblings like get_objects (which discovers IDs) and get_list_view_objects (which focuses on list views).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this tool when you need to examine a specific object's details after discovering its ID through the get_objects tool.' It provides a clear alternative (get_objects for discovery) and a prerequisite (needing an object ID first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully describes key behavioral traits: that results are paginated (important for handling large datasets), and it implies this is a read-only operation by using 'retrieves' and 'provides information'. However, it doesn't mention potential rate limits, authentication requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: purpose statement, details about returned information, and usage guidance. Every sentence adds value - the first establishes core functionality, the second adds important behavioral context (pagination), and the third provides application guidance. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no output schema, the description provides good context: it explains what information is returned (ID, name, access level), mentions pagination behavior, and gives usage guidance. However, without annotations or output schema, it could benefit from more detail about return format structure or error handling. The 100% schema coverage helps compensate for some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema - it doesn't explain space_id format, offset/limit usage patterns, or provide examples. The baseline of 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('retrieves a list of all members'), identifies the resource ('specified Anytype space'), and distinguishes it from siblings by focusing on space membership rather than objects, spaces, or search operations. It goes beyond the tool name by specifying what information is provided about each member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('when you need to understand who has access to a space or manage collaboration permissions'), providing clear context for its application. However, it doesn't specify when NOT to use it or mention alternatives among the sibling tools (like whether get_spaces or search_space might be related alternatives).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool retrieves data (read-only operation), returns a list with IDs, names, and metadata, and that results are paginated. It doesn't mention rate limits, authentication needs, or error conditions, but for a read-only tool with pagination described, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: first states purpose, second explains what templates are, third describes output and pagination, fourth provides usage guidance. It's front-loaded with the core purpose and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description does well by explaining what the return value contains (list with IDs, names, metadata) and pagination behavior. It could mention error cases or authentication requirements, but given the tool's relative simplicity and clear purpose, it's mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain what 'space_id' or 'type_id' represent in context). 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieves') and resource ('all available templates for a specific object type in an Anytype space'), distinguishing it from siblings like get_template_details (which presumably gets details for a single template) and get_types (which gets types rather than templates). It specifies the scope (templates for a specific type in a specific space) and what templates are used for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this tool when you need to find appropriate templates for creating new objects of a specific type.' It distinguishes from alternatives by focusing on template retrieval for a specific type, unlike global_search or search_space which are broader, and get_template_details which likely provides detailed info for a single template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a read operation ('Retrieves'), mentions pagination ('Results are paginated'), and specifies the scope ('available in a specified Anytype space'). However, it doesn't cover potential rate limits, error conditions, or authentication needs, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences, each adding value: the first states the purpose, the second elaborates on the information provided, and the third gives usage guidelines. It's front-loaded with the core functionality and avoids redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a read operation with pagination), no annotations, and no output schema, the description does a good job of covering purpose, usage, and key behaviors. However, it lacks details on return values (e.g., what metadata is included) and error handling, which would be helpful since there's no output schema. It's mostly complete but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing full documentation for all parameters (space_id, offset, limit). The description adds no additional parameter semantics beyond what's in the schema, such as format details or usage examples. According to the rules, with high schema coverage (>80%), the baseline score is 3 when no param info is added in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('all object types available in a specified Anytype space'), specifying what the tool does. It distinguishes from siblings like get_type_details (which gets details for a specific type) and get_objects (which retrieves objects rather than types), making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'when you need to understand what types of objects can be created or to find the correct type ID for creating new objects.' This provides clear context for usage, distinguishing it from alternatives like get_type_details for specific type details or create_object for creating objects, offering explicit guidance on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a list with IDs, names, and metadata, and that no parameters are required. However, it doesn't mention potential limitations like pagination, rate limits, or authentication requirements, which would be helpful for a list 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with zero waste: it states the purpose, details the return value, and provides usage guidance. It's front-loaded with the core action and efficiently covers all necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given 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 mostly complete. It explains what the tool does, what it returns, and when to use it. However, without annotations or an output schema, it could benefit from more detail on the return structure (e.g., format of 'other metadata') or behavioral constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description explicitly states 'No parameters are required,' which adds clarity beyond the empty schema. This is appropriate for a parameterless tool, though it doesn't need to explain non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves'), resource ('Anytype spaces'), and scope ('for the current user'). It distinguishes this tool from siblings like 'get_space_members' or 'create_space' by focusing on listing all spaces rather than modifying or getting details of specific spaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('to get an overview of all spaces or to find a specific space ID for use with other tools'). It implies an alternative use case compared to siblings like 'search_space' (which likely filters) or 'get_space_members' (which focuses on members of a specific space).
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:

[![anytype-mcp MCP server](https://glama.ai/mcp/servers/Qwinty/anytype-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Qwinty/anytype-mcp)

Score Badge

Copy to your README.md:

[![anytype-mcp MCP server](https://glama.ai/mcp/servers/Qwinty/anytype-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Qwinty/anytype-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Qwinty/anytype-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server