MCP Parse Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action, with clear separation between object, schema, role, user, and relation operations. Even similar deletes (field, class, object) are unambiguous due to explicit resource naming.
Naming Consistency5/5
All tools follow a consistent parse_<verb>_<resource> pattern, using clear verbs like create, get, update, delete, list, add, remove, and query. Minor variations like get vs list are contextually appropriate (singular vs plural).
Tool Count4/5
35 tools is above typical ranges, but the server covers the broad domain of Parse Server management including objects, schemas, roles, users, relations, and cloud code. Each tool serves a distinct purpose, making the large count justified for the scope.
Completeness3/5
Object, schema, role, and relation operations have comprehensive CRUD coverage, but user management is incomplete: users can be created, fetched, and listed, yet there are no update_user or delete_user tools. This leaves a notable lifecycle gap.
Average 3.9/5 across 35 of 35 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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, the description carries the full burden. It only states that the function returns a result, but does not disclose potential side effects of executing arbitrary cloud functions, authentication requirements, error behavior, or the wrapper structure (inputSchema). This is insufficient for an execution tool.
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 concise and front-loaded with the core purpose. However, it omits essential structural details, making it efficient but slightly under-specified. It earns a 4 because every word serves a purpose, though clarity could be improved.
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 complex nested schema, lack of output schema, and no annotations, the description is incomplete. It does not explain the required 'inputSchema' envelope, potential side effects, return format, or error conditions. This is inadequate for an agent to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds minimal value beyond the schema's own field descriptions. It does not clarify the nested inputSchema wrapper, which could mislead an agent into providing functionName at the top level. The description should compensate for low coverage but does not.
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 executes a Cloud Function on Parse Server, which is a specific verb+resource. It is distinguishable from sibling tools like parse_run_job or parse_get_cloud_code_info by its focus on direct invocation, though it doesn't explicitly name 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic instructions on what to provide (functionName and optional params) but gives no guidance on when to use this tool versus other parse tools, no exclusions, and no context about prerequisites or alternatives.
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 the full burden but offers only atomicity and unique behavior. It contradicts the schema by stating only primitives (including null) are accepted while the schema allows objects and excludes null. It also does not disclose error cases or effects on non-array fields.
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, straight-to-the-point sentence. It is concise and front-loaded, though the value-type statement could be more precise to avoid contradiction.
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?
The description is very brief relative to the tool's mutation nature. It lacks details about prerequisites, side effects, error conditions, and return behavior. The value-type mismatch with the schema further reduces completeness, making the tool harder to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The top-level 'inputSchema' parameter has no description, and the tool description does not compensate. It adds the unique behavior and value restriction, but the value restriction is misleading and contradicted by the nested schema, which already provides more reliable field descriptions.
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 uses a specific verb ('Añade elementos a un campo array') and identifies the resource (an array field), clearly distinguishing it from sibling tools like parse_remove_from_array and parse_add_relation. It also explains the unique option, which is relevant to the operation.
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 such as parse_add_relation or parse_update_object. The description focuses on mechanism but does not mention prerequisites, scenarios, 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?
No annotations are provided, so the description carries the full burden. It discloses the master key requirement (auth need), but lacks information on side effects, such as schema modification, potential errors if the field exists, or irreversibility. The behavioral transparency is minimal.
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 concise (two sentences) and front-loaded with the action. It efficiently includes parameter names and the master key requirement without wasted words.
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?
This is a mutation tool with no annotations or output schema. The description covers the core purpose and some parameters, but lacks crucial context such as return values, error handling, behavior on duplicate fields, and impact on existing data. The omission of className from the parameter list is a notable gap.
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 0%, and the description partially compensates by listing fieldName, fieldType, targetClass, required, and defaultValue, with fieldType examples. However, it omits className, a required parameter, and the schema already provides property descriptions, so the added value is modest.
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 adds a new field to an existing class, using the specific verb 'Añade' and resource 'campo a una clase existente'. It distinguishes from siblings like parse_delete_field and parse_create_class, though it doesn't explicitly mention alternatives.
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 when to use the tool (when adding a field to an existing class) but doesn't explicitly compare with alternatives or state when not to use. It does mention the master key requirement, providing a precondition for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It indicates a read-only count operation but does not explicitly state that it is non-destructive, mention any required permissions, or describe potential side effects or limitations (e.g., performance on large datasets). The description adds minimal context beyond the core 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using two short sentences to convey the main purpose and the optional filter. There is no redundant or filler content, making it easy to parse.
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?
The tool is simple, but the absence of an output schema means the description should hint at the return format (e.g., a numeric count). It does not. Also, it does not clarify that className is required (though the schema shows it). Overall, the description gives the essential purpose but lacks details about the response and input structure beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'where filters' as an optional parameter. The className parameter is not mentioned at all. While the schema itself describes the parameters, the description does little to compensate for the lack of schema coverage, leaving the agent to infer parameter semantics from the raw schema.
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 action: counting the total number of objects in a Parse Server class. It also mentions the optional 'where' filter, which distinguishes it from sibling tools like parse_query or parse_get_object that return objects rather than counts.
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 for counting objects and optionally filtering, but it does not explicitly contrast with alternatives (e.g., parse_query, parse_aggregate) or state when to prefer this tool over others. No exclusions or prerequisites are provided, only the general scenario.
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?
The description mentions atomicity and primitive-only values, but lacks details on return values, error behavior, removal of all occurrences, or permissions. No annotations exist to fill the gap. The primitive-only claim conflicts with the schema, which allows object items and omits null, undermining 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 two concise sentences, front-loaded with the primary purpose and key constraint. No redundant information is present.
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?
As a mutation tool with no annotations, no output schema, and a nested parameter structure, the description is too sparse. It omits crucial behavioral details like removal semantics, return format, edge cases, and prerequisites, leaving significant gaps for an agent.
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 provides descriptions for nested properties (values, objectId, className, fieldName), but the top-level inputSchema parameter lacks description. The tool description adds context about primitive values, partially compensating for the 0% top-level 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 'Elimina' (remove) and the resource 'un campo array' (an array field), specifying atomic removal of specific elements. This distinguishes it from siblings like parse_add_to_array and parse_remove_relation.
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 the tool is for removing primitive values from an array field, but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or exclusions, leaving usage context to the reader.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses partial-update behavior ('Solo actualiza los campos especificados'), which is useful, but it does not mention permissions, side effects, or return values. This provides minimal but non-trivial 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 two sentences, front-loaded with the action, and contains no filler. Every word adds value, making it highly concise and well-structured.
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?
The tool has a nested parameter structure and no output schema, so the description carries significant weight. It covers the core purpose and partial update behavior, but lacks the inputSchema nesting detail and any mention of response or error conditions, leaving it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It names className, objectId, and data, and notes data is an object with fields to modify, but it fails to mention the top-level 'inputSchema' wrapper required by the schema. This mismatch could confuse an agent about the expected parameter structure.
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 uses a specific verb 'Actualiza' and identifies the resource as 'campos de un objeto existente en Parse Server', which clearly distinguishes it from create/delete tools. It also adds the scope 'Solo actualiza los campos especificados', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It lists required parameters but provides no guidance on when to use this tool versus alternatives like parse_increment_field or parse_add_to_array. There is no explicit 'when/when-not' or mention of alternatives, leaving the agent to 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?
No annotations are provided, so the description must disclose behavioral traits. It only states that multiple operations are executed and mentions method/path/body, but it omits critical details such as atomicity, partial failure behavior, authentication requirements, or rate limits. For a batch tool, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the main purpose. The second sentence gives usage context, and the third covers parameter structure. No unnecessary words.
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 batch operation, the description lacks essential context such as whether operations are atomic, what happens on partial failure, and whether any response format is returned. With no annotations and no output schema, this omission is significant for an AI agent deciding whether to use this tool safely.
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 adds semantic meaning by mapping HTTP methods to actions (POST/crear, PUT/actualizar, DELETE/eliminar), which goes beyond the schema's plain 'Método HTTP' enum. It repeats the structure (method, path, body optional) that the schema already provides, but does clarify the intent of each request. However, it doesn't explain path construction beyond the schema's example.
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 executes multiple operations (POST/create, PUT/update, DELETE/delete) in a single call. This specific verb+resource combination distinguishes it from sibling tools that handle single operations.
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 phrase 'Útil para operaciones masivas' provides clear context for when to use this tool (bulk operations). It doesn't explicitly mention alternatives or exclusions, but the batch nature is clearly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly shows a mutating operation and mentions the return of objectId, but it does not disclose permission requirements, whether the class is created automatically if missing, or possible failure modes. This is useful but incomplete.
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 two concise Spanish sentences, front-loaded with purpose and usage. Every sentence serves a clear function: what the tool does, what inputs to provide, and what it returns. There is no unnecessary fluff.
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 create tool with no output schema and no annotations, the description covers the main inputs and the return objectId. However, it omits important contextual details such as whether the class must exist, permission requirements, and error behavior, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the top-level parameter, and the description only repeats the parameter names ('className' and 'data object with fields and values') without adding format details, allowed types, or examples beyond the nested schema descriptions. It does not meaningfully compensate for the low 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 a specific action ('Crea un nuevo objeto (registro) en una clase de Parse Server') and a specific resource. It distinguishes from siblings like parse_create_class (which creates a class) and parse_update_object (which updates an existing object). The return value (objectId) further reinforces the creation purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage by instructing to provide className and data, but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites such as whether the class must already exist. There are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the core behavior ('removes objects') and lists required inputs, but it does not disclose potential side effects, permissions, or reversibility. This is adequate but not rich.
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, front-loaded sentence with no fluff. It is concise and easy to parse, though the omission of targetClassName slightly detracts from its utility.
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 mutation tool with no annotations and no output schema, the description is incomplete. It fails to mention targetClassName, return values, error conditions, or any prerequisites. The description is too sparse for an operation that modifies data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists most parameters (className, objectId, relationField, objectIds) but omits targetClassName, which is a required parameter in the schema. The nested schema has descriptions, but the description does not fully compensate for the low top-level coverage and misses a required field.
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 action ('Remueve...') and the specific resource ('campo de tipo Relation en Parse Server'), which distinguishes it from sibling tools like parse_remove_from_array and parse_add_relation. The verb and resource are specific and unambiguous.
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 that this tool is for Relation fields, which implies when to use it. It does not explicitly exclude alternatives or mention parse_remove_from_array, but the Relation-field specification gives strong usage guidance.
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 only states the purpose and does not mention error behavior (e.g., what happens if the object doesn't exist), authentication/permissions requirements, or whether include expands pointers. This lacks important context for an agent to fully anticipate the tool's effects.
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 two short sentences in Spanish, immediately stating the objective and use case. It is concise, front-loaded, and contains no unnecessary words or repetition, earning a top score.
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?
This is a simple get operation with no output schema, and the description adequately covers the primary purpose and typical use case. However, it does not disclose error conditions or return format, which would be helpful given the absence of an output schema. The description is sufficient for basic understanding but lacks some completeness.
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 provides descriptions for the nested parameters (include, objectId, className), so the parameters are well-documented at the schema level. The description text only repeats className and objectId but does not explain include. Since schema coverage is effectively high for the actual user-facing fields, the description adds little extra value, warranting a baseline 3.
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 gets a specific object from Parse Server by className and objectId, using the specific verbs 'Obtiene' and 'recuperar'. It distinguishes itself from siblings like parse_query (which queries multiple records) and parse_delete_object by specifying it retrieves a single known record.
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?
It directly says 'Útil para recuperar un registro individual cuando conoces su ID', which provides clear context for when to use the tool (when you know the ID and need a single record). While it doesn't explicitly mention alternatives or exclusions, it implies a distinction from query tools, meeting the threshold for clear context.
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?
The description discloses a key behavioral requirement ('Requiere master key'), which is valuable. However, it does not explain potential side effects, whether the job runs asynchronously, or what the return value is, leaving gaps given there are 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with two sentences that front-load the main action and include essential use cases and auth requirements. Every word contributes to the meaning.
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 tool with a nested parameter object and no output schema, the description is too sparse. It lacks information about how to structure the 'inputSchema', what the job executes, and any return or error behavior, making it incomplete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description should compensate. It does not mention 'jobName' or 'params' at all, leaving the agent without guidance on how to invoke the job correctly. The description adds minimal value beyond the schema.
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 action ('Ejecuta un Background Job') and identifies the resource (a scheduled task in Parse Server). It also gives examples of use cases ('tareas pesadas, limpiezas, reportes'), which distinguishes it from sibling tools like parse_call_cloud_function.
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?
It specifies when to use the tool ('Útil para tareas pesadas, limpiezas, reportes, etc.') providing clear context. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses atomicity, negative values for decrement, and the default amount. However, it does not specify behavior for missing fields, type constraints, or return values. It provides some behavioral context but is not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences in Spanish, front-loading the core functionality. No unnecessary words.
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?
The tool is a simple mutation but lacks annotations and output schema. The description gives core semantics but misses edge cases and return behavior. Given the complexity and available schema, the description is minimally complete but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only mentions 'amount' and its default, while the other parameters (className, objectId, fieldName) are not addressed. The input schema itself contains descriptions, but the description does not compensate for the 0% coverage signal.
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 function: increment or decrement a numeric field atomically, with examples (counters, scores). This distinguishes it from sibling tools like parse_update_object or parse_add_to_array.
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 usage context ('útil para contadores, puntuaciones'), indicating suitable scenarios, but does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It does state the main effect (users lose associated permissions) and the master key requirement, but it omits return value, error behavior, and reversibility, which are meaningful gaps for a mutating 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 two concise sentences, front-loaded with the action, followed by effect and authentication requirement. Every sentence adds value and there is no unnecessary filler.
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 simple mutation tool, the description covers the core operation, effect, and auth prerequisite. However, with no output schema or annotations, it leaves out response format, error cases, and whether the action is reversible, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per the context signal, and the description only mentions 'objectIds' without clearly mapping to the roleId and userIds parameters. The nested schema does provide some descriptions, but the tool description itself fails to compensate for the low 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 uses a specific verb ('Remueve') and a clear resource ('usuarios de un rol'), and the effect ('perderán los permisos') makes the tool's function unambiguous. It is clearly distinct from sibling tools like parse_add_users_to_role.
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 establishes when to use the tool (to remove users from a role) and states a key prerequisite (requires master key). It does not explicitly mention alternatives or when not to use it, but the purpose and sibling context make that obvious.
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 burden. It states the operation is additive ('agrega'), which implies existing relations are preserved. It also explains the conceptual nature of relations. However, it does not disclose behavior around duplicates, invalid objectIds, or permissions, and it omits the targetClassName parameter entirely, leaving a gap in understanding the full mutation.
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 two sentences, front-loaded with the primary action, and includes a brief conceptual note. Every sentence serves a purpose, with no filler or repetition. It is 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description covers the core operation and most parameters but omits targetClassName, a required input. It also lacks details on edge cases, such as duplicate handling or return values. Given the 5-parameter nested schema, the description is only partially 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?
The description adds meaning by explaining className, objectId, relationField, and objectIds in the phrase 'Proporciona className, objectId del objeto que contiene la relación, el nombre del campo de relación y un array de objectIds de los objetos a agregar.' It fails to mention targetClassName, a required parameter. The schema descriptions cover all parameters, but the tool description's partial coverage is not fully compensated, especially given the schema has nested structure.
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 function with a specific verb and resource: 'Agrega uno o más objetos a un campo de tipo Relation en Parse Server' (Adds one or more objects to a Relation field). It differentiates from sibling tools like parse_query_relation and parse_remove_relation by focusing on the add operation for Relation fields, and from parse_add_to_array by targeting Relation rather than Array fields.
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 context on when to use the tool: 'Las relaciones permiten crear vínculos muchos-a-muchos entre objetos' (Relations allow creating many-to-many links). This implies the tool is appropriate for many-to-many relationships. However, it does not explicitly mention alternatives or exclusions, such as preferring parse_add_to_array for array fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions the requirement for a master key, which is useful. However, it does not disclose potential side effects (e.g., aggregation pipelines with $out or $merge which can write data) or performance implications, leaving some ambiguity.
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 short sentences, front-loaded with the core purpose, and contains no redundant information. Every sentence earns its place: what it does, the auth requirement, and when to use it.
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?
The tool is moderately complex with nested parameters and no output schema. The description explains the purpose, gives pipeline examples, and notes the master key requirement. However, it lacks details on return format, potential write operations within pipelines, or usage examples, leaving room for improvement.
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 descriptions are minimal, and the description provides no additional details about className. It does add value by listing example pipeline stages (match, group, sort, project), but this only partially compensates for the lack of parameter-level guidance.
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 executes advanced aggregation queries using a MongoDB pipeline, listing typical stages like match, group, sort, and project. The verb 'Ejecuta' is specific, and the pipeline mention distinguishes it from simpler query tools like parse_query.
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 usage context by stating it is useful for statistics, aggregations, and complex calculations. It does not explicitly contrast with sibling tools, but the 'advanced' qualifier and pipeline explanation imply when to prefer it over simpler query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the required and optional fields and states that a sessionToken is returned for authentication. It does not mention error conditions (e.g., duplicate username), permission requirements, or side effects. This is partial disclosure but lacks depth 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 concise sentence in Spanish that efficiently states the action, requirements, and return value. It avoids unnecessary detail and is well-structured.
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?
The description covers the essential action, required/optional parameters, and return value. However, without an output schema or annotations, it omits details about error handling, permissions, or duplicate user behavior. For a simple create-user tool, it's adequate but not 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?
The schema has zero description coverage for the top-level parameter inputSchema, and the description compensates by listing the required (username, password) and optional (email, additionalFields) fields. However, it does not clarify that these fields are nested inside the inputSchema object, which could lead to invocation errors. It adds some semantic meaning but not fully.
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 'Crea un nuevo usuario en Parse Server' (Creates a new user in Parse Server), using a specific verb and resource. It distinguishes from sibling tools like parse_create_object by targeting users specifically. The mention of required username/password and returned sessionToken further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use (creating a user with mandatory fields) and mentions the return of sessionToken for authentication. However, it does not explicitly contrast with alternative tools (e.g., parse_create_object) or state when not to use it. The requirements (username/password) are clear, but no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behavioral traits: the deletion is permanent ('permanentemente'), data in all objects is lost ('Los datos de ese campo en todos los objetos se perderán'), and master key is required. This thoroughly warns about the destructive and irreversible nature of the 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 highly concise, consisting of two sentences that front-load the core purpose and then state consequences and requirements. Every sentence earns its place without any fluff 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?
Given the tool's destructive nature, the description adequately covers the essential concerns: permanent deletion, data loss, and auth. Although parameter details are left to the schema and no return value is described, the behavioral warnings are sufficient for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the parameters (className and fieldName) and does not compensate for the 0% schema description coverage. It mentions neither parameter, leaving parameter semantics entirely to the schema, which is insufficient for a low-coverage case.
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: 'Elimina permanentemente un campo de una clase' (permanently deletes a field from a class). It uses a specific verb and resource, and distinguishes this from sibling tools like parse_delete_class and parse_delete_object by explicitly focusing on fields.
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 by naming the specific action (delete field) and notes a prerequisite ('Requiere master key'), but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. The context is clear enough, yet there is no direct guidance on 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. It discloses the authentication requirement (master key) and explicitly states the output content (class names, fields, types, permissions). The verb 'Lista' implies a read-only operation, but it could have added more about response format or lack of side effects; still, it provides solid 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action verb, and contains no redundant information. Every word adds value, and the Spanish phrasing is direct and 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?
Given the tool's simplicity (listing schemas) and lack of output schema, the description is fairly complete. It states the scope (all schemas), the type of data returned, and the authentication requirement. It could mention pagination or error conditions, but these are not critical for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'inputSchema' which is an empty object with 0% description coverage. The description does not explain what this parameter is for or why it's required. Since the parameter is essentially a placeholder, the description should have clarified that no additional arguments are needed, but it doesn't.
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 uses a specific verb 'Lista' (lists) and clearly identifies the resource as 'schemas (class structures)' in Parse Server. It also mentions the content shown (class names, fields, types, permissions), which distinguishes it from sibling parse_get_schema (singular) and other schema-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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to list all schemas but doesn't explicitly state when to use it over alternatives like parse_get_schema. It does mention a prerequisite (requires master key) but no exclusions or alternative references.
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 burden of disclosing behavior. It explicitly states 'Requiere master key' (Requires master key), which is an important auth requirement. The read-only nature is implied by the verb 'Lista' but not fully detailed, and there is no mention of output format or side effects. Still, the auth hint adds meaningful transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each providing distinct value: what it lists, why it's useful, and the auth requirement. It is front-loaded and has no filler words.
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?
The description gives the core purpose, a use case, and an auth requirement, but it omits any description of the return value or the unusual `inputSchema` parameter. Because there is no output schema and no annotations, these gaps make the description minimally adequate but not complete for an agent seeking full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter `inputSchema`, which is an object with no properties and additionalProperties false. The description provides zero explanation of this parameter, and schema coverage is 0%. Since the parameter is essentially an empty object, a simple note such as 'No arguments required' would have clarified. The description fails to compensate for the schema's opacity.
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 function: 'Lista todas las Cloud Functions y Background Jobs disponibles en Parse Server' (Lists all Cloud Functions and Background Jobs available in Parse Server). This is a specific verb+resource that distinguishes it from siblings like parse_call_cloud_function or parse_run_job.
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: 'Útil para descubrir qué funciones puedes llamar' (Useful for discovering which functions you can call). This implies when to use the tool, though it does not explicitly mention alternatives or exclusions, which would secure a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the authentication requirement ('Requiere master key') and outlines the schema contents (fields, types, relationships, CLP), providing meaningful behavioral context beyond the function name alone.
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 concise, using two short sentences. The main action and resource are front-loaded, followed by clarifying details and the auth requirement. Every word earns its place.
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 get tool with one parameter and no annotations or output schema, the description sufficiently explains what the returned schema contains, the requirement for master key, and the target scope. It could explicitly state it's read-only, but that is strongly implied by the verb 'obtiene'.
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 input schema already contains a description for className ('Nombre de la clase'). The description adds that the class is specific and what the schema includes, but does not significantly elaborate on the parameter's format or usage beyond the existing schema.
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 'obtiene' and the resource 'schema completo de una clase específica', enumerating fields, data types, relationships, and permissions. This differentiates it from sibling tools like parse_get_schemas by emphasizing a single specific class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single class schema but does not explicitly mention alternatives or exclusions. It notes the prerequisite of a master key, but lacks guidance on when to prefer this tool over parse_get_schemas or other schema-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the master key requirement and filtering behavior, but does not describe the return format, pagination behavior, or explicitly confirm it is read-only. This is moderately 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 a single concise sentence that front-loads the main purpose, includes an example, and mentions the key prerequisite. No wasted 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 list tool with simple semantics, the description covers the essential behavior (list all, filter, limit, master key). It lacks return format details, but given no output schema, this is a minor gap.
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 description explains the 'where' filter with a concrete example and clarifies that 'limit' restricts results. Since the schema has 0% coverage for the actual parameter (inputSchema), the description compensates well by explaining the nested fields.
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 lists all roles in Parse Server, with optional filtering and limit. This distinguishes it from siblings like parse_get_role (single role) and parse_list_users (different resource).
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 mentions the master key requirement and optional filtering/limit, providing context for use. However, it does not explicitly differentiate this tool from parse_get_role or specify when to use this vs 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?
No annotations are provided, so the description carries the full burden. It discloses the master key requirement and the mandatory ACL, which are critical for a create operation. However, it doesn't detail side effects such as failure modes (e.g., duplicate role) or what the response contains, leaving some behavioral aspects uncovered.
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 succinct and front-loaded with the core purpose. It includes a concrete example and key constraints (mandatory ACL, master key) without excessive filler. The length is justified by the need to clarify the non-trivial ACL field.
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 nested object structure, required ACL, and master key requirement, the description covers the essential information: what the tool does, the required fields, an input example, and an authentication note. It doesn't describe return values, but that is not critical for a create operation, and the schema fills in the parameter details.
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 schema already includes descriptions for all nested properties (ACL, name, roles, users), so the baseline is high. The description adds value by explaining the ACL structure with an example, clarifying that ACL is mandatory, and noting that users/roles arrays are optional. This goes beyond the schema to provide semantic meaning.
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 starts with the specific verb 'Crea' (create) and resource 'nuevo rol en Parse Server', clearly stating the purpose is access control. This distinguishes it from sibling tools like parse_get_role, parse_update_role, and parse_delete_role, which cover other lifecycle operations.
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 when to use the tool (creating a new role), and explicitly mentions the master key requirement and mandatory ACL field. It doesn't spell out 'do not use if the role already exists', but the word 'nuevo' (new) implies it, making the usage context clear without explicit exclusions.
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 discloses that the deletion is permanent, that users with the role lose associated permissions, and that master key authentication is required. This is strong for a destructive operation, though it doesn't detail error cases or response formats, so a 4 is appropriate.
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 two concise sentences, front-loaded with the core action. Every sentence adds value: the action, the effect on users, and the auth requirement. No redundancy or filler.
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 deletion tool with one parameter and no output schema, the description covers the essential context: what is deleted, the side effect, and the required authorization. It lacks examples or error handling, but these are not critical for such a straightforward tool, making it sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description itself adds no parameter information. The sole parameter is described in the schema (objectId del rol a eliminar), but the tool description does not clarify or enhance this. Since coverage is low, the description was expected to compensate, which it does not, resulting in limited value beyond the schema.
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 action ('Elimina permanentemente un rol de Parse Server') with a specific verb and resource. It distinguishes from siblings like parse_delete_object or parse_delete_class by explicitly targeting roles, and it mentions the consequence on users' permissions, further clarifying its scope.
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 when to use this tool: to permanently delete a role, with the explicit prerequisite that a master key is required. It does not explicitly list alternatives or when not to use, but the resource-specific nature makes the usage context clear, so it earns a 4 rather than a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden; it discloses the master key requirement and the special syntax values, which are important behavioral constraints. However, it does not state whether the call overwrites or merges existing permissions, what the response looks like, or whether the class must already exist.
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 two sentences, front-loads the purpose, and every clause earns its place by defining scope, value syntax, and a prerequisite. No filler or redundancy.
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 nested-parameter tool with no output schema and no annotations, the description covers the core syntax and auth requirement but omits likely-needed context about overwrite behavior, return values, and error conditions. It is minimally viable but not fully complete.
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?
Even though schema description coverage is 0%, the description explains the semantics of the only parameter's values ('*', 'requiresAuthentication', 'role:RoleName'), which is not obvious from the boolean schema. It adds meaning beyond the input schema, though it does not detail the nested permissions structure further.
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 opens with 'Define permisos a nivel de clase' and enumerates the specific permissions (get, find, create, update, delete, addField), making the tool's purpose concrete and distinct from sibling schema/class tools. The verb 'Define' plus the CLP resource clearly states what operation is performed.
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?
It clearly scopes the tool to class-level permissions and provides the accepted value formats ('*', 'requiresAuthentication', 'role:RoleName'), which tells the agent when this is appropriate. It does not explicitly contrast with sibling tools like parse_update_schema, so it stops short of a full usage-vs-alternatives explanation.
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 present, so the description carries the transparency burden. It discloses that the operation modifies existing roles and requires master key, but it does not clarify whether the ACL is replaced or merged, does not mention return values, error behavior, or reversibility. Some context is added, but substantial gaps remain.
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 two concise sentences, front-loaded with the action and resource. It includes necessary alternative tooling and auth requirement without fluff, making every word earn its place.
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 mutation tool with no annotations and no output schema, the description covers the core purpose, auth requirement, and distinguishes user-management operations. However, it lacks behavioral details such as ACL replacement semantics, response format, and error cases. The nested schema adds some context, but the absence of annotations leaves the tool only partially 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?
The schema contains a single top-level parameter (inputSchema) with nested properties. The description explicitly mentions 'nombre' and 'ACL', which maps to name and ACL, but it omits objectId and does not explain the inputSchema wrapper. However, the schema itself provides descriptions for each property, so the description adds some semantic value but does not fully compensate for the low 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 'Modifica' and the resource 'rol existente', specifying the exact attributes being changed (name or ACL). It distinguishes itself from sibling tools like parse_add_users_to_role and parse_remove_users_from_role by explicitly redirecting user management operations to those tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use context: modify role name/ACL. It also gives direct alternatives for user management ('Para gestionar usuarios del rol usa...') and notes the master key requirement, which is a usage prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a master key requirement, which is an auth-related behavioral trait. However, it does not mention what happens if the class already exists, idempotency, error behavior, or access/security implications beyond the master key note. For a mutation tool, more transparency about side effects would be valuable.
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 two concise sentences: the first states the core action, and the second details the configurable components and the master key requirement. Every sentence delivers useful information without redundancy or unnecessary elaboration.
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 complexity of the nested input schema, the description covers the essential aspects: purpose, field structure, optional CLP, and key prerequisite. It lacks return value/error details, but for a creation tool with a detailed schema, this is reasonably complete. The absence of an output schema shifts emphasis to input clarity, which is well handled.
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 schema has 0% top-level parameter description coverage, but the description actively compensates by explicitly outlining the inputSchema structure: 'Define className, fields (nombre: {type, targetClass, required, defaultValue}) y opcionalmente classLevelPermissions.' This adds practical meaning beyond the raw schema, clarifying the expected field format and optional elements.
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: 'Crea una nueva clase (tabla) en Parse Server con su estructura de campos' with a specific verb (creates) and resource (class/table). It further enumerates what can be defined (className, fields, classLevelPermissions), distinguishing it from sibling tools like parse_delete_class or parse_update_schema.
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 gives clear context for when to use this tool (to create a new class) and mentions a key prerequisite ('Requiere master key'). However, it does not explicitly state when not to use it or contrast with alternatives (e.g., using parse_update_schema for existing classes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the deletion is permanent ('permanentemente'), which is a crucial behavioral trait for a destructive operation. With no annotations provided, this disclosure adds significant value beyond simply saying 'delete'. It does not mention return values or side effects, but for this tool, permanence is the key 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the purpose and immediately list the required parameters. No redundant words or filler; every element contributes to understanding the tool.
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 delete operation with two parameters and no output schema, the description is reasonably complete. It covers the action, the permanence, and the required inputs. It does not describe the response or error cases, but those are less critical for a basic deletion tool. Given the lack of annotations and output schema, it could have been more detailed, but the essentials are present.
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 both required parameters (className and objectId) and their purpose ('del objeto a eliminar'), which compensates somewhat for the reported 0% schema description coverage. However, it does not add extra meaning beyond what the schema already states (the schema includes descriptions for both). This is adequate but not exceptional.
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 'Elimina permanentemente un objeto de Parse Server' (permanently deletes an object from Parse Server), specifying the verb (delete), resource (object), and the service (Parse Server). It distinguishes from sibling tools like parse_delete_class and parse_delete_field by focusing on object deletion and requiring className and objectId.
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 when to use this tool: when you need to delete an object from Parse Server, and explicitly states the required parameters (className and objectId). It does not explicitly mention alternatives or exclusions, but the context and sibling list make the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the master key requirement and optional filter/limit behavior. It implies a read-only operation ('lista') but doesn't explicitly state safety or response format, though the master key disclosure adds meaningful 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each with clear purpose: main action, optional parameters, and authentication requirement. No wasted 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?
Given the simple listing purpose and lack of output schema, the description is mostly complete. It covers the main functionality and required permission. It doesn't describe response shape or pagination, but those are not critical for tool selection. The missing inputSchema nesting detail is a minor gap.
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 has 0% coverage for the top-level parameter, and the description explains where and limit with an example. However, it doesn't clarify that these values must be nested inside an 'inputSchema' object, which could lead to incorrect invocation. The description adds value but misses the structural nuance.
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 'Lista todos los usuarios' (lists all users), distinguishing it from siblings like parse_get_user and parse_create_user. It also mentions optional filtering and limit, making its scope unambiguous.
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 use: it lists all users with optional where filtering and limit, and states the master key requirement. It doesn't explicitly compare to alternatives, but the purpose is evident enough to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explains the where syntax and lists supported features, which is helpful. However, it does not explicitly state that the operation is read-only or describe the response format, leaving some behavioral ambiguity.
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 concise, consisting of two sentences. It front-loads the core purpose and then provides a compact example of the where syntax. Every sentence adds value without unnecessary fluff.
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?
The description covers the main capabilities and gives syntax examples, making it fairly complete for a complex query tool. It lacks explicit mention of the return format and the 'count' behavior, but these are documented in the schema. Given no annotations or output schema, it does a good job but has minor gaps.
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?
Schema description coverage is reported as 0%, so the description must compensate. It does so by explaining the where syntax (equality, $gt, etc.) and naming key parameters like where, order, limit, skip, keys, and include. This adds meaningful context beyond the schema, especially for the complex 'where' parameter.
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 it queries multiple objects of a class in Parse Server, with specific capabilities like filtering, ordering, pagination, field selection, and relation inclusion. The verb 'Consulta' and resource 'múltiples objetos de una clase' distinguish it from sibling tools such as parse_get_object (single object) and parse_count.
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 gives clear context for when to use this tool: when querying multiple objects with filters, ordering, pagination, etc. It does not explicitly mention alternatives or exclusions, but the scope is well-defined by listing the supported features, making it obvious 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It openly describes the tool as a read-only query operation ('Consulta y obtiene') and mentions supported behaviors (filter, sort, paginate). It does not expose potential side effects because it is inherently non-destructive, which aligns with the query semantics.
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 succinct, consisting of two sentences that front-load the primary action and then detail the supported capabilities. There is no extraneous information.
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?
The description, combined with a well-detailed input schema, provides sufficient context for using the tool. It lacks an explicit mention of required parameters (className, objectId, relationField), but the schema marks them required, and the description's focus on relation fields makes the tool's purpose clear.
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 only generically mentions 'filtros, ordenamiento y paginación' without naming actual parameters. The input schema itself provides detailed descriptions for each parameter, so the agent can still infer correct usage. The description adds minimal value beyond the schema, hence a baseline score of 3.
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 'Consulta y obtiene' (query and get), the resource 'objetos relacionados en un campo de tipo Relation' (related objects in a Relation field), and distinguishes itself from general query tools by specifically targeting relation fields.
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: it is for exploring existing relationships via filters, sorting, and pagination. It does not explicitly name alternatives or exclusion criteria, but the purpose is evident among sibling tools like parse_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral disclosure burden. It explicitly states the operation is permanent ('Elimina permanentemente'), irreversible ('Esta operación es irreversible'), and requires a master key. It also clarifies that ALL objects of the class are deleted, which is a critical destructive 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential action and consequences. Every word earns its place, with no redundant or filler content.
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 1-parameter destructive tool with no output schema, the description covers the main points: action, scope (all objects), irreversibility, and auth requirement. It does not mention error handling or return value, but these are less critical for a class deletion operation. The description is nearly complete for the tool's context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not mention the className parameter. It only refers to 'una clase' without specifying how to pass it. The description does not compensate for the lack of parameter documentation, leaving the parameter semantics entirely to the schema, which is minimal.
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 action: 'Elimina permanentemente una clase y TODOS sus objetos de Parse Server' (permanently deletes a class and ALL its objects). It uses a specific verb and resource, and distinguishes from siblings like parse_delete_field and parse_delete_object by indicating class-level deletion.
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 when to use the tool: to delete an entire class and all its objects. It mentions the prerequisite 'Requiere master key' (requires master key), implying high privilege. It does not explicitly name alternatives, but the scope is clear enough for an agent to infer this is not for deleting individual fields or objects.
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. It discloses important behavioral traits: the operation requires the master key, the role must exist, and users inherit the role's permissions. This goes beyond a simple mutation statement and helps the agent understand side effects and prerequisites.
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 two sentences, front-loaded with the action, and every word adds value. It avoids unnecessary detail while covering the action, effect, and a critical prerequisite.
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 mutation tool with two parameters and no output schema, the description provides the essential purpose, prerequisite, and behavioral effect, which is sufficient for an agent to select and invoke it correctly. It does not mention idempotency or error handling, but those are not critical for initial tool selection.
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?
Although the schema has 0% description coverage at the top level, the description clarifies the meaning of the parameters: 'objectIds' refers to user IDs and the role is identified by its objectId. This compensates for the sparse schema and gives the agent enough semantic information to map inputs correctly.
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 adds one or more users to an existing role via objectIds, which is a specific action distinct from sibling tools like parse_remove_users_from_role. It also notes the permission inheritance effect, reinforcing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to grant role permissions to users) and provides context such as the requirement that the role already exist and that master key is required. It does not explicitly mention alternatives or exclusions, but the clear purpose and sibling list make usage boundaries evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the auth requirement (master key) and what the tool returns (name, ACL, user relationships). It does not mention error behavior, but as a read-only get operation, this is sufficient. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence is front-loaded with the purpose, and the second adds a key prerequisite. No fluff 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 simple get tool with one parameter and no output schema, the description covers the return fields and auth requirement. It lacks error handling details, but it is otherwise complete for the tool's complexity.
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?
Schema description coverage for the actual parameter (inputSchema) is 0%, so the description must compensate. It explicitly mentions 'objectId' and indicates it identifies the role. This adds semantic value beyond the schema, though it does not describe the nested structure, which the schema provides.
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 ('Obtiene los detalles') and resource ('rol específico'), and specifies the exact output details (nombre, ACL, relaciones con usuarios). This distinguishes it from sibling tools like parse_list_roles (list all roles) and parse_get_object (generic object getter).
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?
It states a clear prerequisite (requires master key), which is useful for when to use it. However, it does not explicitly mention alternative tools or when not to use it. The context (fetch role details by objectId) is clear, but without exclusions, it does not achieve a 5.
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 full burden and adds meaningful behavioral context: it excludes password from output and requires master key. This goes beyond a simple 'get details' statement, though it doesn't cover error behavior or missing-user handling.
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 two concise sentences in Spanish, front-loaded with the core purpose (get specific user by objectId) followed by key output and permission details. Every sentence earns its place, with no filler.
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 one-parameter getter with no output schema, the description covers the return content (username, email, custom fields), excludes password, and notes master key requirement. It is complete enough for an agent to invoke correctly, though not-found behavior could be added.
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?
Schema description coverage is 0%, but the description explicitly states the operation is by objectId, clarifying the single parameter's role. This compensates for the lack of schema-level detail and makes the parameter's purpose unambiguous.
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 retrieves a specific user by objectId and specifies the returned fields (username, email, custom fields, excluding password). This distinguishes it from sibling tools like parse_get_object (generic object retrieval) and parse_get_role (specific role retrieval).
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 implies use when you need details of a single user by objectId and notes the master key requirement. It does not explicitly list alternatives or exclusions, but the context is clear enough for an agent to select it over list or generic retrieval 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, the description carries the full burden. It discloses that the tool mutates the schema, requires master key, and cannot delete fields. While it doesn't describe side effects on existing data, it clearly communicates the key behavioral constraints.
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 compact, with two sentences that front-load the main action and resource, followed by a limitation/alternative and an auth note. Every sentence contributes value 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 mutation tool with complex nested schema and no output schema, the description covers purpose, usage conditions, limitations, and an alternative. It doesn't mention return values, but the schema makes the request structure clear, and the description is sufficiently detailed for an agent to know when and how to invoke it.
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 description adds meaningful context by explaining that 'fields' is for adding/modifying and 'classLevelPermissions' is for updating CLP. It also clarifies the limitation on deletion, which affects how the fields parameter should be used. The schema itself has thorough descriptions for nested properties, so this complements rather than repeats.
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 modifies an existing class schema, adding fields or updating CLP, and distinguishes itself from sibling tool parse_delete_field by explicitly noting it cannot delete fields. The verb 'Modifica' and resource 'schema de una clase existente' make the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use (adding fields or updating CLP) and when not to use (cannot delete fields, pointing to parse_delete_field as the alternative). Also mentions the master key requirement, which is a crucial prerequisite.
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:

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

Score Badge

Copy to your README.md:

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

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/emanuelmartin/mcp-parse-server'

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