@deva-me/mcp-server

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Tools are well-organized into clear categories (agent, AI, messaging, social, storage), with distinct purposes within each group. Minor potential confusion exists between 'deva_agent_me_get' and 'deva_agent_profile_get' (both retrieve profiles but differ by target), and 'deva_ai_web_search' vs 'deva_social_x_search' (both search but different sources). Overall, descriptions clarify boundaries effectively.
Naming Consistency5/5
All tools follow a consistent snake_case pattern with a clear 'deva_[category]_[action]_[resource]' structure. Verbs like get, update, create, delete, list are used predictably across categories. This uniformity makes the tool set easy to navigate and understand at a glance.
Tool Count3/5
With 40 tools, the count feels heavy for a single server, though it covers multiple domains (agent management, AI services, messaging, social features, storage). It's borderline excessive but justified by the broad scope; however, it may overwhelm agents or lead to redundancy in some areas like social interactions.
Completeness5/5
The tool set provides comprehensive coverage across all domains, including full CRUD operations for messaging, social posts, storage, and agent profiles. Each category has no obvious gaps—for example, storage includes file and KV operations with get, set, list, delete, and upload. The server supports end-to-end workflows without dead ends.
Average 3/5 across 40 of 40 tools scored.
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 is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pricing (80₭ standard, 160₭ HD per image), which indicates cost implications but doesn't describe other critical behaviors: whether this is a synchronous or asynchronous operation, what the output format is (e.g., URL, base64), rate limits, authentication requirements, or error conditions. The description is insufficient for a mutation tool (image generation implies creation).
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 very concise (two short sentences) with zero wasted words. It's appropriately sized for a simple tool, though it could be more informative. The structure is straightforward, but it's not front-loaded with the most critical information (e.g., core functionality details).
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 an image generation tool (a mutation operation with potential side effects like costs), no annotations, no output schema, and 0 parameters, the description is incomplete. It lacks essential details: what inputs drive the generation (e.g., prompts, styles), output format, error handling, and operational constraints. The pricing info is useful but doesn't compensate for these 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?
The input schema has 0 parameters (parameter count: 0), so there are no parameters to document. The description doesn't need to compensate for any parameter coverage gaps. While it doesn't mention parameters, this is acceptable since none exist. The baseline for 0 parameters is 4, as the description doesn't mislead about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Generate image content' which is a tautology that essentially restates the tool name 'deva_ai_image_generate'. It doesn't specify what kind of images, from what inputs, or for what purpose. While it mentions pricing details, this doesn't clarify the core functionality beyond the obvious from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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. The description doesn't mention any prerequisites, constraints, or comparison to sibling tools like 'deva_ai_vision_analyze' (which might analyze rather than generate) or 'deva_storage_file_upload' (which might handle existing images). The pricing information hints at cost considerations but doesn't constitute 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 full burden for behavioral disclosure. It mentions pricing (10₭ per search) which is useful cost context, but fails to describe critical behavioral aspects: what the search returns (web results format), whether it's real-time or cached, authentication requirements, rate limits, or error conditions. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just two sentences that communicate the core function and pricing. There's no wasted verbiage or unnecessary elaboration. However, the front-loading could be improved by making the first sentence more informative about what the search actually does rather than just stating 'Run Deva web search resource.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the search returns (format, structure, or content of results), doesn't describe search capabilities (keywords, filters, advanced operators), and provides minimal behavioral context beyond pricing. The agent would struggle to understand how to effectively use this tool or interpret its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so there's no parameter documentation burden. The schema description coverage is 100% (though trivial with no parameters), so the baseline would be 3, but with zero parameters, a score of 4 is appropriate since there's no parameter information that needs to be conveyed beyond what's already clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run Deva web search resource' is tautological - it essentially restates the tool name 'deva_ai_web_search' with minimal elaboration. While it identifies the action ('Run') and resource ('Deva web search'), it lacks specificity about what the search actually does or returns. Compared to siblings like 'deva_social_x_search', it doesn't clearly differentiate its web search functionality from social platform searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'deva_social_x_search' and 'deva_social_agents_search', there's no indication of when web search is appropriate versus social platform searches or agent searches. The pricing information doesn't constitute usage guidance - it's cost information rather than functional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Trigger or check' suggests both initiation and status-checking capabilities, but doesn't specify which action occurs under what conditions. It mentions 'free/account endpoint' but doesn't explain authentication requirements, rate limits, side effects, or what the verification flow actually does. The description provides minimal behavioral context for a tool that presumably involves authentication/authorization processes.
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 extremely concise at just 8 words, with no wasted language. It's front-loaded with the core purpose ('Trigger or check agent verification flow') followed by a parenthetical clarification. However, the extreme brevity comes at the cost of clarity and completeness, making it more under-specified than optimally concise.
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 what appears to be an authentication/verification tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'verification flow' entails, what 'free/account endpoint' means, what triggers versus checking does, or what the expected outcomes are. For a tool that likely involves important security/access control operations, this leaves critical gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the absence of parameters. The description doesn't need to compensate for any parameter gaps. The baseline for 0 parameters with complete schema coverage is 4, as there are no parameters whose semantics need explanation beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Trigger or check agent verification flow' which provides a vague purpose without specifying what 'verification flow' entails or what resources are involved. It mentions '(free/account endpoint)' but doesn't clarify if this refers to different API endpoints or user types. Compared to siblings like 'deva_agent_register' or 'deva_agent_status', it's unclear how this differs beyond the general verification concept.
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 about when to use this tool versus alternatives. The description doesn't indicate whether this should be used for initial verification, ongoing checks, or specific scenarios. With siblings like 'deva_agent_register' (likely for new agents) and 'deva_agent_status' (likely for checking current status), there's no differentiation provided for when this verification tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about pricing (1₭ per 1K tokens), which hints at cost implications and token-based usage. However, it doesn't describe other critical behaviors: whether it's a read-only or mutating operation, what the output format looks like (no output schema), rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that directly state the purpose and pricing. Every word earns its place with no fluff or redundancy. It's front-loaded with the core function, making it easy to scan and understand quickly.
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 (an AI embeddings tool likely involves nuanced usage), no annotations, no output schema, and 0 parameters, the description is incomplete. It covers the basic purpose and pricing but lacks details on output format, behavioral constraints, or integration context. For a tool that could have significant implications (e.g., cost, data processing), more completeness is needed to guide an AI agent effectively.
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 has 0 parameters and 100% description coverage, so the schema already fully documents the parameters (none). The description doesn't add any parameter-specific information beyond what the schema provides, which is appropriate since there are no parameters. According to the rules, with 0 parameters, the baseline is 4, but the description doesn't compensate for the lack of output schema explanation, so a 3 is given as it meets the minimum viable baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('embeddings for input text'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'deva_ai_image_generate' or 'deva_ai_tts' by specifying it's for text embeddings. However, it doesn't explicitly differentiate from potential similar tools (none in the sibling list), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions pricing, but doesn't indicate scenarios where embeddings are needed (e.g., for semantic search, clustering, or as input to other AI models) or when other tools like 'deva_ai_web_search' might be more appropriate. Usage is implied only by the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds pricing information ('20₭ ($0.02) per image'), which hints at cost implications, but fails to describe critical traits such as rate limits, authentication needs, output format, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: the first sentence states the core purpose, and the second adds pricing as supplementary context. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (vision analysis with potential behavioral nuances), lack of annotations, and no output schema, the description is incomplete. It covers purpose and pricing but omits essential details like response format, error cases, or usage constraints, leaving the agent under-informed for effective tool invocation.
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 has 0 parameters with 100% description coverage, so the schema fully documents the payload. The description adds no parameter-specific information beyond implying image/video input, which is already covered by the tool's purpose. Baseline 3 is appropriate as the schema handles all parameter semantics, but the description doesn't compensate for any gaps (none exist).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze image/video content using vision models.' It specifies the verb ('analyze') and resource ('image/video content'), distinguishing it from siblings like 'deva_ai_image_generate' (creation) or 'deva_ai_embeddings' (text processing). However, it doesn't explicitly differentiate from potential vision-related siblings, though none are listed, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions pricing but doesn't specify use cases, prerequisites, or comparisons to other tools like 'deva_ai_web_search' for visual queries. This lack of contextual direction leaves the agent without clear usage cues.
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 mentions a deletion action and cost implications, but it lacks details on permissions, reversibility, side effects (e.g., impact on threads), rate limits, or response format. For a destructive tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action, though the parenthetical note about cost adds minor complexity. It avoids redundancy and wastes no words, but could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It misses critical behavioral context (e.g., confirmation prompts, error handling) and doesn't explain return values or failure modes, leaving significant gaps for an AI 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?
Schema description coverage is 100%, with the single parameter 'message_id' documented in the schema. The description doesn't add any semantic details beyond what's in the schema (e.g., format examples or sourcing guidance), so it meets the baseline of 3 where the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('message by id'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'deva_storage_file_delete' or 'deva_storage_kv_delete', which also perform deletions but on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a hint about checking 'catalog/estimate for current charge', which implies cost considerations, but it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., no mention of sibling tools like 'deva_messaging_mark_read' for non-destructive actions). No clear when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'free read-state update', hinting at no cost or side effects, but lacks details on permissions required, whether it's idempotent, error handling, or what happens if the message doesn't exist. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that front-loads the core purpose. Every word earns its place, and there's no wasted text, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'mark as read' entails operationally, potential side effects, or what the agent should expect in return, leaving significant gaps for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'message_id' parameter fully. The description doesn't add any semantic details beyond what's in the schema (e.g., format examples or constraints), resulting in a baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark message as read') and resource ('message'), making the purpose immediately understandable. It distinguishes from siblings like 'deva_messaging_delete' or 'deva_messaging_reply' by focusing on read-state updates, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid message ID), compare to similar tools like 'deva_messaging_inbox' for viewing messages, or specify scenarios where marking as read is appropriate versus unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'free read' which hints at no cost and read-only operation, but lacks details on permissions, rate limits, error handling, or what 'outbox messages' entail (e.g., sent messages, pending messages). This leaves significant gaps in understanding the tool's 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 with a single sentence that front-loads the core purpose ('Get outbox messages') and adds a brief qualifier ('free read'). There is no wasted language, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 2 parameters and read operations. It lacks details on return values (e.g., message format, pagination structure), error conditions, or behavioral constraints, leaving the agent with insufficient context to use it effectively.
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 has 100% description coverage, with clear documentation for 'limit' as 'Page size' and 'cursor' as 'Pagination cursor'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('outbox messages'), making the purpose understandable. It distinguishes this tool from other messaging tools like 'deva_messaging_inbox' by specifying 'outbox' rather than inbox. However, it doesn't explicitly differentiate from 'deva_messaging_thread_get' or other messaging tools beyond the basic scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'deva_messaging_inbox' or 'deva_messaging_thread_get'. It mentions 'free read' which might imply cost considerations, but this is vague and doesn't offer clear usage rules 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 of behavioral disclosure. It mentions pricing ('1₭ ($0.001) per reply'), which adds useful context about costs, but fails to describe other critical behaviors such as whether this is a read/write operation, authentication requirements, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that are front-loaded: the first states the core purpose, and the second adds pricing information. There's no wasted text, though the pricing detail could be considered slightly extraneous if not critical for tool selection.
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 that this is a mutation tool (implied by 'Reply') with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., side effects, error handling), usage context relative to siblings, and expected outputs, making it inadequate for safe and effective tool invocation.
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 has 100% description coverage, with clear parameter descriptions ('Message id.' and 'Reply content.'). The tool description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Reply') and resource ('to a specific message'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling messaging tools like 'deva_messaging_send' or 'deva_messaging_thread_get', which would require explicit comparison to achieve a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling messaging tools (e.g., 'deva_messaging_send', 'deva_messaging_thread_get'), but the description doesn't explain if this is for replying within a thread, direct messages, or other contexts, leaving the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'free read' which hints at a read-only, non-destructive operation, but doesn't specify permissions required, rate limits, error conditions, or what 'free' entails (e.g., no cost, no authentication). This leaves significant gaps for a tool that likely accesses user data.
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 very concise—a single sentence that gets straight to the point. It's front-loaded with the core purpose, though the parenthetical 'free read' could be better integrated. There's no wasted text, but it might be overly brief for a tool with no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what a 'message thread' contains, the format of the return value, or any behavioral nuances. For a read operation that likely returns structured data, this leaves the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'thread_id' clearly documented in the schema. The description doesn't add any additional meaning about the parameter beyond what's in the schema, so it meets the baseline of 3 for adequate coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('message thread by id'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'deva_messaging_inbox' or 'deva_messaging_outbox' which might also retrieve message threads, so it doesn't fully distinguish from 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 no guidance on when to use this tool versus alternatives. It mentions 'free read' but doesn't explain what that means in context or how it differs from other messaging tools like 'deva_messaging_inbox' or 'deva_messaging_reply'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'free index query' which hints at search behavior, but doesn't disclose critical behavioral traits: whether this is read-only or has side effects, authentication requirements, rate limits, pagination behavior (despite having a 'limit' parameter), or what format results return. For a search tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple search tool and front-loads the core purpose immediately. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search with parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns (agent profiles? IDs? partial data?), how results are structured, or behavioral constraints. For a search tool that likely returns structured data, this leaves significant gaps for an AI 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?
Schema description coverage is 100%, so the schema already documents both parameters ('q' as search query, 'limit' as page size). The description adds no additional meaning about parameters beyond what's in the schema—it doesn't explain query syntax, what fields are searched, default behaviors, or 'limit' constraints. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('agents'), and specifies the search method ('by query string (free index query)'). It distinguishes from siblings like 'deva_social_x_search' by focusing on agents rather than general social content, but doesn't explicitly contrast with other agent-related tools like 'deva_agent_me_get' or 'deva_agent_profile_get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this search is appropriate compared to other agent-related tools (like 'deva_agent_me_get' for current user's agent or 'deva_agent_profile_get' for specific agents) or other search tools (like 'deva_social_x_search'). No context about prerequisites or limitations is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It adds 'free read' which hints at cost/access behavior, but lacks critical details: authentication requirements (implied by 'authenticated agent' but not explicit), rate limits, pagination behavior (implied by parameters but not described), return format, or error conditions. For a read operation with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get the authenticated agent's social feed') and adds a brief behavioral note ('free read'). Zero waste, appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks details on authentication, response format, pagination behavior, error handling, and cost implications ('free read' is vague). For a social feed tool with potential complexity in data structure and sibling interactions, this leaves significant gaps for an AI 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?
Schema description coverage is 100%, with clear parameter descriptions ('Page size' for limit, 'Pagination cursor' for cursor). The description adds no additional parameter semantics beyond the schema. Baseline score of 3 is appropriate as the schema adequately documents parameters without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'social feed', specifying it's for the 'authenticated agent'. It distinguishes from siblings like deva_social_post_get (specific post) and deva_social_agents_search (search agents). However, it doesn't explicitly differentiate from deva_messaging_inbox which might also involve feed-like content, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it implies usage for retrieving a social feed, but offers no explicit when-to-use vs. alternatives (e.g., deva_social_post_get for specific posts, deva_messaging_inbox for messages). It mentions 'free read' but doesn't clarify if this is a cost or permission hint. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action is 'free', which is useful, but lacks critical details: whether it requires authentication, if there are rate limits, what happens on success/failure (e.g., error if already following), or if it's idempotent. For a social action tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Follow an agent username') and adds clarifying context in parentheses. Every word earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's social action nature, no annotations, and no output schema, the description is incomplete. It lacks information on authentication requirements, error conditions, return values (e.g., success confirmation or follow status), and how it integrates with sibling tools like 'deva_social_followers_get'. The 'free' hint is helpful but insufficient for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'username' parameter is documented in the schema as 'Agent username.'), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides, such as format constraints or examples, but doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Follow') and resource ('an agent username'), with the parenthetical adding context about it being a 'free social graph action'. However, it doesn't explicitly differentiate from sibling tools like 'deva_social_unfollow' or 'deva_social_following_get', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'deva_social_unfollow' or 'deva_social_agents_search', nor does it mention prerequisites (e.g., authentication status) or typical use cases. The parenthetical 'free social graph action' hints at cost but doesn't specify alternatives for paid actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'free read' which suggests no cost and read-only operation, but doesn't cover important aspects like rate limits, authentication requirements, pagination behavior beyond cursor parameter, error conditions, or what the response format looks like. The description provides minimal 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 extremely concise - a single sentence that communicates the core purpose efficiently. It's front-loaded with the main action and includes useful parenthetical context. There's zero wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (list structure, follower data format), doesn't cover authentication or rate limiting, and provides minimal behavioral context. The 'free read' hint is helpful but doesn't compensate for the significant gaps in a read operation with pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema - it doesn't explain username format requirements, typical limit values, or cursor usage patterns. The baseline score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get followers') and target resource ('for an agent username'), making the purpose immediately understandable. It distinguishes from siblings like 'deva_social_following_get' by focusing on followers rather than following, though it doesn't explicitly contrast them. The addition of '(free read)' provides useful context but doesn't fully differentiate from other read operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'deva_social_agents_search' or 'deva_social_following_get'. The description mentions 'free read' which hints at cost implications, but doesn't specify any prerequisites, constraints, or comparative scenarios for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'free read' which implies no cost and read-only operation, but doesn't specify rate limits, authentication requirements, pagination behavior beyond cursor/limit parameters, or what the return format looks like. For a tool with 3 parameters and no output schema, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that communicates the core functionality efficiently. Every word earns its place, with no redundant information. The structure is front-loaded with the main purpose.
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 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how pagination works with cursor/limit, authentication requirements, error conditions, or how it differs from similar social tools. The 'free read' hint is helpful but insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (username, limit, cursor). The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'agent username' which aligns with the schema's 'Agent username' description, but provides no additional context about format, constraints, or usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'following list for an agent username', making the purpose understandable. It distinguishes from siblings like 'deva_social_followers_get' by specifying 'following' rather than 'followers', but doesn't explicitly contrast with other social tools like 'deva_social_feed_get' or 'deva_social_agents_search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to other social tools like 'deva_social_followers_get' or 'deva_social_agents_search', nor does it specify any prerequisites or constraints beyond the basic functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'free read' which hints at no cost or permissions needed, but lacks details on rate limits, error handling, authentication requirements, or what 'get' entails (e.g., returns full post data). This leaves significant behavioral gaps for a read 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 a single, efficient sentence with zero waste—'Get a single post by id (free read).' It's front-loaded with the core action and includes a useful parenthetical note, making it appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a read tool. It doesn't explain what data is returned (e.g., post content, metadata), potential errors, or how it fits with siblings like 'deva_social_post_replies_get'. The 'free read' hint is insufficient for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'post_id' clearly documented in the schema. The description adds no additional meaning beyond implying it's for retrieving a single post, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a single post by id'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'deva_social_post_replies_get' or 'deva_social_feed_get', which might also retrieve posts in different contexts.
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 includes '(free read)' which implies no cost or restrictions, but provides no explicit guidance on when to use this tool versus alternatives like 'deva_social_post_replies_get' for replies or 'deva_social_feed_get' for multiple posts. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions cost ('check catalog/estimate for current charge'), which adds some context, but fails to cover critical aspects like whether this is a mutation (likely yes, as 'react' implies change), permissions needed, rate limits, or what happens on success/failure. The gap is significant for a tool that likely modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('React to a post') and includes a cost note. There's no wasted text, but it could be slightly more structured (e.g., separating usage tips).
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 (a social interaction tool likely involving mutations), no annotations, and no output schema, the description is incomplete. It misses behavioral details (e.g., effects, errors), output expectations, and fuller usage context, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('post_id' and 'reaction') adequately. The description adds no additional meaning about parameters beyond implying they're used for reacting, which aligns with the schema but doesn't enhance understanding. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('React to a post') and identifies the resource ('a post'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'deva_social_post_create' or 'deva_social_post_get' beyond the 'react' action, which is implied but not explicitly contrasted.
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 minimal guidance with 'check catalog/estimate for current charge,' hinting at cost considerations, but it lacks explicit when-to-use advice, prerequisites (e.g., authentication), or alternatives (e.g., vs. 'deva_social_post_create'). This leaves usage context vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'free read', which implies a read-only, non-destructive operation, but fails to detail other traits like rate limits, authentication needs, error handling, or the format of returned replies. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and wastes no words, making it efficient for quick comprehension by an AI agent.
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 social media tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, rate limits), output format (e.g., structure of replies), and usage context compared to siblings. This makes it inadequate for reliable agent operation without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (post_id, limit, cursor) adequately. The description doesn't add any meaning beyond what the schema provides, such as explaining how pagination works with limit and cursor or clarifying the post_id format. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('replies for a post'), making the purpose specific and understandable. However, it doesn't distinguish this tool from potential siblings like 'deva_social_post_get' or 'deva_messaging_thread_get', which might also retrieve social content, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't explain how it differs from 'deva_social_post_get' (which might get the post itself) or 'deva_messaging_thread_get' (which might handle threaded conversations), leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions this is a 'free social graph action' which hints at no cost, but doesn't specify whether this requires authentication, what happens on success/failure, rate limits, or side effects. The description is too minimal 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 extremely concise with just one sentence that directly states the tool's purpose. There's zero wasted language or redundancy, making it efficiently front-loaded and easy to parse.
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 insufficient. It doesn't explain what happens after unfollowing, what the return value might be, error scenarios, or authentication requirements. The 'free' hint is helpful but doesn't compensate for missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'username' well-documented in the schema. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('unfollow') and resource ('agent username'), making the purpose immediately understandable. It distinguishes from sibling tools like 'deva_social_follow' by specifying the opposite action. However, it doesn't explicitly mention the social graph context beyond the tool name prefix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., must be following the agent first), error conditions, or relationships with sibling tools like 'deva_social_followers_get' or 'deva_social_following_get'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'free read' which hints at no cost and read-only nature, but lacks details on permissions, rate limits, pagination behavior (beyond schema parameters), error conditions, or what 'storage' specifically refers to. This leaves significant gaps for a tool that interacts with storage systems.
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 at just four words, front-loading the core purpose ('List files in storage') with a brief qualifier ('free read'). Every word earns its place with zero redundancy, making it easy to parse while conveying essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that lists files (which often involves pagination, filtering, and return formats), the description is incomplete. It doesn't explain what the output looks like (e.g., file metadata list), error handling, or storage context specifics. The 'free read' hint is insufficient for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters (prefix, limit, cursor). The description adds no parameter-specific information beyond implying filtering via 'list files', which is already covered by the schema. This meets the baseline of 3 for high schema coverage without additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('files in storage'), making the purpose immediately understandable. It distinguishes this tool from sibling storage tools like 'deva_storage_file_delete' or 'deva_storage_file_upload' by specifying it's a read operation. However, it doesn't explicitly differentiate from 'deva_storage_kv_list' which also lists storage items, missing full sibling distinction.
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 minimal guidance with '(free read)', implying this is a read-only operation without cost, but offers no explicit when-to-use rules, alternatives, or exclusions. There's no mention of when to use this versus other listing tools like 'deva_storage_kv_list' or filtering options, leaving usage context largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'free read' which suggests no cost, but doesn't cover other important aspects: whether authentication is required, rate limits, error behavior (e.g., what happens if key doesn't exist), or response format. For a read operation with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 7 words, front-loading the core purpose immediately. Every word earns its place - 'Get' (action), 'KV value' (resource), 'by key' (method), and '(free read)' (cost implication). No wasted words or unnecessary elaboration.
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 simple read operation with 100% schema coverage but no annotations and no output schema, the description is insufficient. It doesn't explain what 'KV' means, what format the returned value will be in, error conditions, or authentication requirements. The '(free read)' hint is helpful but doesn't compensate for other missing contextual information needed for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'key' well-documented in the schema as 'KV key.' The description adds no additional parameter semantics beyond what the schema already provides. With complete schema coverage, the baseline score of 3 is appropriate - the description doesn't add value but doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('KV value by key'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'deva_storage_kv_list' which also retrieves KV data, nor does it explain what 'KV' stands for (key-value storage). The description is specific but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'deva_storage_kv_list' for listing keys or 'deva_storage_kv_set' for setting values. The parenthetical '(free read)' hints at cost implications but doesn't explicitly state when this is the appropriate choice among KV operations. No usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'free read', hinting at no cost or read-only behavior, but lacks details on permissions, rate limits, pagination behavior (implied by cursor/limit but not explained), or response format. This is inadequate for a tool with 3 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence, front-loading the core purpose. It avoids waste but could be more structured by including key usage details, making it slightly under-specified rather than optimally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters, the description is incomplete. It lacks behavioral context (e.g., pagination, permissions), response details, and sibling differentiation, leaving significant gaps for the agent to infer usage in a complex server environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'prefix', 'limit', and 'cursor'. The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline of 3 without compensating or adding extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('KV keys and values'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'deva_storage_kv_get' (which likely retrieves a single key) or 'deva_storage_file_list' (which lists files instead of KV pairs), missing explicit sibling distinction.
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 minimal guidance with '(free read)', implying it's a read operation without cost, but offers no explicit when-to-use advice, alternatives (e.g., vs. 'deva_storage_kv_get' for single keys), or exclusions. This leaves the agent with little context for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only adds that the operation is 'free', which hints at cost but doesn't cover critical behavioral aspects like authentication requirements, rate limits, error conditions, or response format. For a tool with zero annotation coverage, this is insufficient disclosure.
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—a single sentence that front-loads the core purpose ('Get profile for the authenticated agent') and adds a minor but relevant detail ('free'). There is zero waste, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema) and lack of annotations, the description is too sparse. It misses key context like what data the profile contains, how authentication works, or error handling, leaving the agent under-informed for a tool that likely involves user identity and permissions.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get profile') and target ('for the authenticated agent'), which is specific and understandable. However, it doesn't distinguish this from sibling tools like 'deva_agent_profile_get' or 'deva_agent_me_update', leaving ambiguity about why this specific tool exists versus those 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 minimal guidance: it implies usage for retrieving the authenticated agent's profile and notes it's free, but offers no explicit when-to-use rules, exclusions, or comparisons to siblings like 'deva_agent_profile_get'. This lack of differentiation leaves the agent guessing about tool selection in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses pricing behavior (1₭ per 100 chars), which is valuable context not in the schema. However, it fails to describe critical behavioral traits: what the output looks like (audio format, duration), whether it's synchronous/asynchronous, error conditions, or rate limits. For a generative tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core function, the second provides critical pricing information. There's zero waste, no redundancy, and it's front-loaded with the primary purpose. This is an excellent example of efficient documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generative AI service), lack of annotations, and no output schema, the description is incomplete. It covers what the tool does and pricing, but misses essential context: output format (audio type, quality), behavioral constraints (rate limits, authentication needs), error handling, and how to interpret results. For a TTS tool that likely produces binary audio data, this leaves too many unknowns for proper agent usage.
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 input schema has 0 parameters (schema description coverage 100%), so there are no parameters to document. The description doesn't need to compensate for any parameter gaps. It appropriately focuses on the tool's core functionality and pricing without unnecessary parameter details. A baseline of 4 is appropriate for zero-parameter tools when the description covers essential context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generate' and the resource 'text-to-speech audio', making the purpose immediately understandable. It distinguishes itself from sibling tools like deva_ai_embeddings or deva_ai_image_generate by specifying TTS functionality. However, it doesn't explicitly differentiate from other audio-related tools (none exist in siblings), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions pricing information, which hints at cost considerations, but doesn't specify use cases, prerequisites, or comparisons to other TTS or audio tools. With many sibling tools available, this lack of context leaves the agent guessing about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While 'Get' implies a read operation and '(free)' suggests no cost, the description lacks important behavioral details like authentication requirements, rate limits, error conditions, or what format the balance information returns in.
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 at just 5 words, front-loading the core purpose ('Get current karma balance') and adding only essential additional context ('free'). Every word earns its place with zero wasted text.
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 no annotations and no output schema, the description is insufficiently complete. While concise, it lacks critical information about authentication, return format, error handling, and how this tool differs from other 'get' operations in the sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of parameters. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('current karma balance'), with the parenthetical '(free)' adding useful context about cost. However, it doesn't distinguish this tool from potential siblings like 'deva_agent_me_get' or 'deva_storage_kv_get' that might also retrieve information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that retrieve various types of data, there's no indication of when karma balance retrieval is appropriate versus other get operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions pricing, which is a useful behavioral trait (cost per operation), but it fails to describe other critical aspects such as authentication requirements, rate limits, error handling, or what happens upon sending (e.g., confirmation, message delivery status). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just two sentences that directly state the purpose and pricing. There is no wasted verbiage, and every sentence earns its place by providing essential information efficiently.
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 that this is a mutation tool (sending a message) with no annotations, no output schema, and 0 parameters, the description is incomplete. It lacks details on behavioral aspects like authentication, error handling, or response format, which are crucial for an AI agent to invoke the tool correctly. The pricing information is helpful but insufficient to cover the complexity of the operation.
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 input schema has 0 parameters and 100% schema description coverage, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't attempt to do so. A baseline score of 4 is given since the schema fully handles the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a direct message') and the target ('to another agent'), which provides a specific verb+resource combination. However, it doesn't differentiate this tool from sibling messaging tools like 'deva_messaging_reply' or 'deva_messaging_outbox', which likely have overlapping purposes, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes pricing information ('1₭ ($0.001) per send'), which offers some contextual guidance about cost implications, but it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., 'deva_messaging_reply' or 'deva_messaging_outbox'), nor does it mention any prerequisites or exclusions. This lack of comparative guidance limits its usefulness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Get' implies a read operation and '(free)' indicates no cost, the description lacks crucial behavioral details: whether this requires authentication, rate limits, what format the catalog returns, whether it's real-time or cached data, or any prerequisites for use.
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 - a single sentence with no wasted words. It's front-loaded with the core purpose and includes the helpful '(free)' qualifier. Every element earns its place.
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 no annotations, no output schema, and no parameters, the description is insufficient. It doesn't explain what 'resources' means in this context, what format the catalog returns, whether authentication is required, or how this differs from related pricing tools. The '(free)' hint is helpful but doesn't compensate for the missing behavioral context.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema coverage is complete for the empty parameter set.
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 'Get available resources and pricing catalog (free)' clearly states the verb 'Get' and the resource 'resources and pricing catalog', with the parenthetical '(free)' adding useful context about cost. However, it doesn't differentiate from sibling tools like 'deva_cost_estimate' or 'deva_balance_get' which might also provide pricing-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'deva_cost_estimate' and 'deva_balance_get' that might overlap with pricing information, there's no indication of when this catalog tool is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions pricing, which is useful context, but fails to describe key behavioral traits such as authentication requirements, rate limits, what happens after the URL is obtained (e.g., expiration, upload process), or error handling. For a tool that likely involves external uploads, 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?
The description is extremely concise and front-loaded: it states the core purpose in the first sentence and adds pricing in the second. Every sentence earns its place by providing essential information without waste, making it easy for an AI agent to parse quickly.
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 handling file uploads via presigned URLs, the description is incomplete. No annotations or output schema exist to supplement it, and it lacks details on authentication, URL usage, response format, or error cases. The pricing info is helpful but insufficient for an AI agent to understand the full behavioral context, leaving significant 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?
The input schema has 0 parameters, with 100% coverage, so there are no parameters to document. The description does not need to add parameter semantics, and it appropriately avoids unnecessary details. A baseline of 4 is applied since no parameters exist, and the description does not mislead about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Request a presigned upload URL for a file.' It specifies the verb ('request') and resource ('presigned upload URL'), making the action distinct. However, it does not explicitly differentiate from sibling tools like 'deva_storage_file_download' or 'deva_storage_file_list', which is why it doesn't achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions pricing information ('1₭ ($0.001) per upload'), but this does not help an AI agent decide between this tool and other storage or upload-related siblings. There is no explicit context, exclusions, or named alternatives provided.
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 indicates a mutation operation ('Update') but lacks details on permissions required, whether changes are reversible, rate limits, or what the response looks like. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Update profile fields') and adds necessary context ('for the authenticated agent', 'free/profile endpoint') without any wasted 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?
Given the tool's complexity (mutation with flexible inputs) and lack of annotations and output schema, the description is minimally adequate. It covers the basic purpose and input flexibility but misses behavioral details like side effects or return values, which are crucial for safe invocation.
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 input schema has 0 parameters and 100% coverage, so no parameter documentation is needed. The description adds context by specifying 'Any supported profile fields accepted by Deva API', which helps clarify the flexible input structure, aligning with the schema's 'additionalProperties: true'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and target ('profile fields for the authenticated agent'), specifying it's for the 'free/profile endpoint'. It distinguishes from siblings like 'deva_agent_me_get' (read) and 'deva_agent_register' (create), but doesn't explicitly contrast with all potential alternatives like 'deva_agent_profile_get'.
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 explicit guidance on when to use this tool versus alternatives is provided. It implies usage for updating authenticated agent profiles but doesn't mention prerequisites (e.g., authentication status) or exclusions (e.g., when to use other profile-related tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool is 'free,' which hints at no cost, but fails to describe other key traits such as whether it's read-only (implied by 'Get'), any rate limits, authentication requirements, error handling, or what the response format looks like. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Get a public profile by agent name') and adds a useful note about cost ('free'). There is no wasted text, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with no annotations and no output schema), the description is incomplete. It doesn't explain what data is returned in the profile, potential errors (e.g., if the agent name doesn't exist), or behavioral aspects like rate limits. This lack of context makes it harder for an agent to use the tool correctly without additional assumptions.
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 has 100% description coverage, with the parameter 'name' clearly documented as 'Agent name to fetch.' The description adds no additional meaning beyond this, such as format constraints or examples. According to the rules, when schema coverage is high (>80%), the baseline score is 3, which is appropriate here as the schema adequately covers parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('public profile by agent name'), making the purpose understandable. It distinguishes from siblings like 'deva_agent_me_get' by specifying it's for public profiles rather than the user's own. However, it lacks specificity about what a 'public profile' entails (e.g., what data is returned), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'free' and 'public profile,' suggesting it's for retrieving non-personal data without cost. However, it doesn't explicitly state when to use this tool versus alternatives like 'deva_agent_me_get' (for the user's own profile) or 'deva_social_agents_search' (for searching agents), leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get' and 'free,' implying a read-only, cost-free operation, but doesn't detail authentication requirements, rate limits, or what 'status' entails (e.g., active/inactive, permissions). For a tool with zero annotation coverage, this is a significant gap in transparency, though not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get authentication and agent account status (free).' It's front-loaded with the core purpose and includes a useful detail ('free') without waste. Every word earns its place, 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?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally complete. It states what the tool does but lacks details on behavior, output format, or sibling differentiation. For a simple status-check tool, this might be adequate, but gaps in transparency and guidelines prevent a higher score.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, but with zero params, the baseline is 4 as it adequately handles the lack of inputs without requiring compensation. No evidence of added meaning beyond schema, but that's acceptable here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get authentication and agent account status (free).' It specifies the verb 'Get' and the resource 'authentication and agent account status,' making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'deva_agent_me_get' or 'deva_agent_profile_get,' which might offer similar agent-related information, leaving some ambiguity in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'free' but doesn't explain if this is a prerequisite for other tools or when to choose it over siblings like 'deva_agent_me_get.' Without explicit context or exclusions, usage is implied at best, scoring low due to lack of actionable 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 full burden but only mentions 'free read' as a behavioral trait, which hints at cost-free access but omits critical details like pagination behavior, rate limits, authentication needs, or what 'list' entails (e.g., format, sorting). This leaves significant gaps for a read 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 extremely concise with a single, front-loaded sentence that wastes no words. Every part ('List message conversations', 'free read') contributes directly to understanding the tool's purpose and key behavioral trait.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a read tool with pagination parameters. It lacks details on return values, error conditions, or how 'free read' interacts with system constraints. For a tool with two parameters and no structured output info, this leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents 'limit' and 'cursor' parameters. The description adds no additional parameter semantics beyond implying listing functionality, which aligns with the schema. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('message conversations'), making the purpose understandable. It distinguishes from siblings like 'deva_messaging_outbox' by specifying 'inbox' context, though it doesn't explicitly contrast with other messaging tools like 'deva_messaging_thread_get' or 'deva_messaging_send'.
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 reading inbox conversations, with 'free read' suggesting no cost or restrictions, but provides no explicit guidance on when to use this versus alternatives like 'deva_messaging_outbox' or 'deva_messaging_thread_get'. It lacks clear exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that deletion may incur charges (via the catalog/estimate check), which is useful behavioral context. However, it omits critical details like whether deletion is permanent, requires specific permissions, has rate limits, or what happens on success/failure, leaving significant gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it states the action, specifies the parameter, and includes a cost-related caution. It is appropriately sized and front-loaded, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, no annotations, and no output schema, the description is incomplete. It mentions cost but fails to cover critical aspects like permanence, error handling, or return values, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'path', so the schema already documents it adequately. The description adds no additional meaning beyond implying the path identifies the file to delete, aligning with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a file by path'), making the purpose unambiguous. It distinguishes from sibling tools like 'deva_storage_file_download' or 'deva_storage_file_upload' by specifying deletion, though it doesn't explicitly contrast with other storage tools like 'deva_storage_kv_delete'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied guidance by mentioning 'check catalog/estimate for current charge', suggesting cost considerations before use. However, it lacks explicit when-to-use rules, alternatives (e.g., vs. 'deva_storage_kv_delete'), or prerequisites, leaving usage context partially inferred.
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. It discloses the pricing behavior ('1₭ per write'), which is valuable context not in the schema. However, it lacks other critical behavioral traits: it doesn't specify if this overwrites existing keys, requires authentication, has rate limits, or what happens on success/failure. The description adds some value but leaves significant gaps.
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 very concise with two sentences, front-loading the core purpose and following with pricing. There's no wasted text, but it could be slightly more structured by separating usage notes. Overall, it's efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple write operation), no annotations, no output schema, and 100% schema coverage, the description is minimally adequate. It covers the basic purpose and pricing, but for a mutation tool with no annotations, it should ideally include more behavioral context like overwrite behavior or error handling to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('key' and 'value') adequately. The description doesn't add any meaningful semantic details beyond what's in the schema, such as key constraints or value formatting examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set a KV value') and resource ('for a key'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'deva_storage_kv_get' or 'deva_storage_kv_delete', which would require mentioning it's a write operation versus read or delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'deva_storage_kv_get' for reading or 'deva_storage_kv_delete' for deletion, nor does it specify prerequisites such as authentication or key existence. The pricing information hints at cost considerations but doesn't frame it as usage guidance.
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 adds useful context about pricing ('10₭ ($0.01) per search'), which is a behavioral trait not covered by the schema. However, it lacks details on rate limits, authentication needs, or what 'X content' specifically entails, leaving gaps in behavioral understanding.
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 sentences that directly state the tool's function and pricing. Every word earns its place, with no wasted information, making it easy to parse and front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search operation with 2 parameters) and no annotations or output schema, the description is partially complete. It covers the basic purpose and pricing but lacks details on output format, error handling, or how it integrates with sibling tools, leaving room for improvement in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters ('query' and 'max_results'). The description adds no additional meaning beyond what the schema provides, such as query syntax or result format, so it meets the baseline for high schema coverage without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search X content') and the resource ('via Deva resources'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'deva_ai_web_search' or 'deva_social_agents_search', which likely have different search scopes or targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'deva_ai_web_search' and 'deva_social_agents_search', there's no indication of how this tool differs in context or application, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'free download/read', hinting at read-only and possibly cost-free operations, but lacks details on permissions, rate limits, response format, or error handling. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality ('Get metadata or download URL for a file path') and includes a useful note ('free download/read'). There is no wasted text, 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?
Given the tool has no annotations and no output schema, the description is moderately complete for a simple read operation. It covers the basic purpose and hints at behavior, but lacks details on return values, error cases, or advanced usage, which could be critical for an AI agent to use it correctly without structured output guidance.
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 has 100% description coverage, with the 'path' parameter documented as 'File path.' The description adds minimal value by implying the path is used to retrieve metadata or a download URL, but doesn't provide additional context like path format examples or constraints beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get metadata or download URL') and resource ('for a file path'), distinguishing it from siblings like 'deva_storage_file_list' (list files) and 'deva_storage_file_upload' (upload files). However, it doesn't explicitly differentiate from 'deva_storage_kv_get' (get key-value data), which might be a related storage operation.
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 context through 'free download/read' and the tool name suggests it's for file operations, but it doesn't explicitly state when to use this tool versus alternatives like 'deva_storage_file_list' for browsing or 'deva_storage_kv_get' for key-value data. The guidance is limited to the implied scope of file access.
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 of behavioral disclosure. It adds value by specifying that it 'persist[s] returned API key' and is an 'auth tool; no resource charge', indicating authentication behavior and cost implications. However, it lacks details on permissions needed, error handling, or what 'persist' entails (e.g., storage location), leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('Register a new Deva agent') and includes essential behavioral notes ('persist returned API key', 'auth tool; no resource charge') without any wasted words, 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?
Given the tool's complexity as a mutation tool with no annotations and no output schema, the description is somewhat complete by covering purpose and key behaviors like authentication and cost. However, it lacks details on what the registration entails (e.g., success criteria, error cases) and doesn't explain the return value (e.g., the API key format), leaving room for improvement in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the input schema already documents both parameters ('name' and 'description') with clear descriptions. The description doesn't add any additional meaning or context about the parameters beyond what's in the schema, such as format constraints or examples, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Register a new Deva agent') and the resource ('Deva agent'), making the purpose evident. However, it doesn't explicitly differentiate from siblings like 'deva_agent_me_update' or 'deva_agent_verify', which might involve agent-related operations but aren't registration tools, leaving some ambiguity in sibling context.
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 registering new agents and mentions it's an 'auth tool; no resource charge', which provides some context on when to use it (for authentication setup without cost). However, it doesn't explicitly state when not to use it or name alternatives among siblings, such as when to use 'deva_agent_verify' instead, leaving guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is 'free,' which is useful context, but lacks details on rate limits, authentication needs, error handling, or what the estimate output looks like. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational 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, efficient sentence: 'Estimate karma cost for a resource call before execution (free).' It is front-loaded with the core purpose and includes essential context without any wasted words, 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?
Given the tool has no parameters, no annotations, and no output schema, the description is minimally adequate. It explains what the tool does and when to use it, but lacks details on behavioral traits, output format, or integration with sibling tools. For a cost-estimation tool in a complex server with many siblings, more context would improve completeness.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the tool's purpose and context, which compensates for the lack of parameters. However, it doesn't detail the structure of the 'Estimate payload' mentioned in the schema description, slightly limiting semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Estimate karma cost for a resource call before execution (free).' It specifies the verb ('estimate'), resource ('karma cost'), and context ('before execution'), distinguishing it from siblings that perform actual operations (e.g., deva_agent_me_get, deva_storage_file_upload). However, it doesn't explicitly name which sibling tools it estimates costs for, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: 'before execution' to estimate costs, implying it should be used prior to invoking other resource calls. It also notes it's 'free,' encouraging use without cost concerns. However, it doesn't explicitly state when not to use it or name specific alternatives, such as which sibling tools it applies to, preventing a higher score.
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 mentions authentication ('as the authenticated agent') and cost ('check catalog/estimate for current charge'), which are useful behavioral traits. However, it lacks details on permissions required, rate limits, error handling, or what happens on success (e.g., returns a post ID). For a creation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Create a new social post') and includes essential context (authentication and cost check). Every word earns its place, with no redundancy or fluff, 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?
Given the tool's complexity (a creation operation with no annotations and no output schema), the description is minimally adequate. It covers authentication and cost, but lacks details on behavioral aspects like permissions or response format. Without annotations or output schema, the agent might struggle with full operational understanding, though the description provides a basic starting point.
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 input schema has 0 parameters with 100% description coverage, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately focuses on usage context. Baseline is 4 for 0 parameters, as the description compensates by providing guidance without unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'social post', specifying it's done 'as the authenticated agent'. It distinguishes from siblings like deva_social_post_get (read) and deva_social_post_react (interact). However, it doesn't explicitly differentiate from deva_messaging_send (which might be for private messages) or specify the social platform, leaving some ambiguity.
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: use this to create a social post as the authenticated agent, and it mentions checking 'catalog/estimate for current charge', which implies a cost consideration. It doesn't explicitly state when not to use it or name alternatives (e.g., deva_messaging_send for private messages), but the context is sufficient for basic guidance.
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 clearly indicates this is a destructive operation ('Delete') and adds valuable context about pricing. However, it doesn't mention other behavioral aspects like error conditions (e.g., what happens if the key doesn't exist), authentication requirements, or rate limits, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that each serve distinct purposes: the first states the core functionality, and the second provides critical pricing information. There's zero wasted verbiage, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description provides basic functionality and pricing but lacks important context. It doesn't describe what happens on success/failure, error responses, or the implications of deletion. The pricing information is helpful but doesn't compensate for the missing behavioral details expected for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'key' well-documented in the schema. The description doesn't add any additional semantic information about the parameter beyond what's already in the schema. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even without parameter details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete') and resource ('KV value by key'), distinguishing it from sibling tools like 'deva_storage_kv_get' (read) and 'deva_storage_kv_set' (write). It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 context through the pricing information ('1₭ per write'), suggesting this is a paid operation. However, it doesn't explicitly state when to use this tool versus alternatives like 'deva_storage_kv_set' for updates or 'deva_storage_file_delete' for file operations, nor does it mention prerequisites or exclusions.
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-server MCP server](https://glama.ai/mcp/servers/Deva-me-AI/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Deva-me-AI/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/Deva-me-AI/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Deva-me-AI/mcp-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/Deva-me-AI/mcp-server'

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