Skip to main content
Glama

anytype_get_object

Retrieve a specific object from Anytype by providing its space and object IDs, enabling access to stored content and data.

Instructions

Obtiene un objeto específico por su ID

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
space_idYesID del espacio
object_idYesID del objeto

Implementation Reference

  • The core handler function that executes the tool logic: extracts space_id and object_id from arguments, makes an API GET request to retrieve the object, and returns the response as formatted text content.
    export async function handleGetObject(args: any) {
      const { space_id, object_id } = args;
      const response = await makeRequest(`/v1/spaces/${space_id}/objects/${object_id}`);
      return { content: [{ type: 'text', text: JSON.stringify(response, null, 2) }] };
    }
  • The tool definition including name, description, and inputSchema for validation (requires space_id and object_id). Part of the objectTools array.
    {
      name: 'anytype_get_object',
      description: 'Obtiene un objeto específico por su ID',
      inputSchema: {
        type: 'object',
        properties: {
          space_id: { type: 'string', description: 'ID del espacio' },
          object_id: { type: 'string', description: 'ID del objeto' },
        },
        required: ['space_id', 'object_id'],
      },
    },
  • src/index.ts:126-127 (registration)
    Registration in the main CallToolRequestHandler switch statement: dispatches tool calls matching 'anytype_get_object' to the handleGetObject function.
    case 'anytype_get_object':
      return await handleGetObject(args);
  • src/index.ts:85-93 (registration)
    Combines all tool schemas into the tools array (via spread of objectTools which includes anytype_get_object schema) for ListToolsRequestHandler response.
    const tools = [
      ...spaceTools,
      ...objectTools,
      ...propertyTools,
      ...typeTools,
      ...tagTools,
      ...templateTools,
      ...listTools,
    ];
  • Uses the shared makeRequest utility from utils.ts to perform the HTTP request (imported at line 1). Note: full makeRequest implementation is in src/utils.ts.
    const response = await makeRequest(`/v1/spaces/${space_id}/objects/${object_id}`);
    return { content: [{ type: 'text', text: JSON.stringify(response, null, 2) }] };
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/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 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/5

Given 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/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', '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/5

Does 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/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 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.

Install Server

Other Tools

Latest Blog Posts

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