Server Quality Checklist

Tool Scores

• solucortex_recallA
  4.1/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint and openWorldHint, so the description adds net-new value by explaining that only approved/active memories are returned, that results are ranked, and that the tool relies on slower OpenAI embeddings with a 20 req/min rate limit. This is exactly the operational context an agent needs beyond annotation flags.

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

  Conciseness5/5

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

  Three compact sentences cover the operation, when to use it, what it returns, and its performance caveat. Every sentence earns its place, and the key usage instruction is front-loaded.

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

  Completeness4/5

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

  For a read-only retrieval tool with an output schema and fully described parameters, the description covers purpose, timing, return behavior, and rate limiting. It would be fully complete with explicit routing to sibling tools for one-off searches or alternative retrieval cases.

  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%, and the schema already explains the query and project_id parameters well. The tool description adds no new parameter-specific semantics beyond the general semantic retrieval concept, so the baseline 3 is appropriate.

  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 names a concrete endpoint (`POST /context/build`) and states it returns approved, active memories ranked by semantic similarity and importance. It clearly identifies the tool's job, but it does not explicitly differentiate it from sibling tools like `solucortex_search`.

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

  Usage Guidelines4/5

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

  It gives a strong, explicit trigger condition: call this at the START of a task, before touching code. However, it does not provide when-not-to-use guidance or mention alternative tools for other retrieval needs.

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

• solucortex_list_memoriesA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context: it is a plain GET endpoint, does no semantic search, and 'Does not consume OpenAI quota'. This is useful beyond the annotations, though it does not discuss auth or pagination details.

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

  Conciseness5/5

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

  Three short sentences, each earning its place: the operation, the use cases, and the quota-relevant behavior. The key distinction 'without semantic search' is front-loaded.

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

  Completeness5/5

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

  For a simple read-only list operation with a full input schema and an output schema present, the description provides enough context for correct selection and invocation. It even notes the practical use cases and the non-OpenAI-quota behavior.

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

  Parameters3/5

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

  Schema description coverage is 100%, and both limit and project_id already have clear descriptions in the schema. The tool description adds no additional parameter semantics, so the baseline 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'List the project's memories' and clarifies the operation is 'without semantic search (GET /memories)'. This clearly distinguishes it from semantic-search siblings like solucortex_search or solucortex_recall.

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

  Usage Guidelines4/5

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

  It explicitly states when to use the tool: 'quick inspection/audit or to confirm a just-created memory was stored'. It implies the alternative is semantic search by saying 'without semantic search', but it does not name sibling tools or state when not to use them explicitly.

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

• solucortex_searchA
  4.5/5.0
  Behavior4/5

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

  Annotations already signal readOnlyHint and openWorldHint, so the description does not need to restate safety. It adds useful behavioral context beyond annotations: it is ad-hoc rather than context-building, uses OpenAI embeddings, and carries a 20 req/min rate limit. This gives the agent operational expectations that the annotations do not.

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

  Conciseness5/5

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

  Three short sentences deliver purpose, usage guidance, sibling differentiation, an example, and a rate limit with no waste. The most important information is front-loaded before the longer guidance.

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

  Completeness5/5

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

  The description covers when to use the tool, how it differs from the main sibling, and an operational constraint. Combined with full schema descriptions, annotations, and an output schema, an agent has everything needed to select and invoke this tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters. The description reinforces that the query is a question or topic and that this is semantic search, but it does not add meaning beyond the schema. Baseline 3 is appropriate because the schema carries the parameter-semantics burden.

  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 states a specific action and resource: "Ad-hoc semantic search of memories" with the exact endpoint POST /search/semantic. It distinguishes the tool from recall by noting that recall "builds the full startup context," so an agent can tell them apart without opening schemas.

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

  Usage Guidelines5/5

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

  It explicitly says when to use this tool: "Use for specific questions during a task" and gives a concrete example. It also names the closest alternative, solucortex_recall, and explains the distinction, which is clear routing guidance.

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

• solucortex_rememberA
  4.7/5.0
  Behavior5/5

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

  Beyond the annotations' write hint, it discloses that the memory is stored with status 'approved' and traced, requires a Bearer api_key, and imposes a handling policy for secrets. This is meaningful behavioral context that the annotations do not provide.

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

  Conciseness5/5

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

  Three sentences with no filler. The purpose is front-loaded, the trigger condition follows, and the secret-handling policy is compact but complete.

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

  Completeness5/5

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

  With a 100%-covered input schema, an output schema, and annotations covering the write/safety profile, the description covers the remaining contextual need: when to call it and how to handle secrets. Nothing essential is missing for an agent to invoke it correctly.

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

  Parameters4/5

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

  Schema coverage is 100%, so the parameters are already well documented. The description adds extra semantic guidance for the content field: if a secret is found, record location/type/severity and action taken with a redacted reference. This is a modest but real addition beyond the schema's 'NEVER include real secrets' note.

  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?

  Description opens with a specific verb-resource pair ('Record a memory in SoluCortex (POST /memories)') and makes the write intent unambiguous. This clearly distinguishes it from the sibling retrieval tools solucortex_recall, solucortex_search, and solucortex_list_memories.

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

  Usage Guidelines4/5

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

  It gives an explicit trigger: 'Call when closing a task or making a relevant technical decision.' It does not explicitly exclude retrieval or name sibling alternatives, but the when-to-use guidance is clear enough for an agent to select it correctly.

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