Keeta Network MCP Server

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by explaining the dynamic runtime discovery system, auto-resolution of arguments, and the three subtarget types with their specific behaviors. It mentions seed omission for read-only operations (implied in schema but reinforced here). Could improve by explicitly stating whether operations are read-only or mutating.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear opening statement, bulleted subtarget explanations, and specific guidance sentences. Every sentence serves a distinct purpose with zero wasted content, making it easy to parse despite the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 9-parameter tool with no annotations and no output schema, the description provides substantial context about the execution model, subtarget semantics, and discovery mechanisms. It references related tools for additional functionality. Could be more complete by explaining return value expectations or error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3, but the description adds significant value by explaining the semantic meaning of subtarget types (service, lib, metadata) with concrete examples, clarifying the relationship between parameters, and providing discovery guidance that goes beyond schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes ANY anchor operation on the Keeta Network with fully dynamic runtime discovery. It distinguishes from siblings by specifying this is for anchor operations specifically, unlike keeta_client_execute or keeta_user_client_execute which handle different execution contexts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use different subtargets (service, lib, metadata) and directs users to keeta_list_sdk_methods for discovery. It also references keeta_client_execute for argument resolution rules, creating clear relationships with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.