OpenLMlib

by Vedant9500

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
Multiple tools have heavily overlapping purposes: search_knowledge/search_findings/retrieve_findings/retrieve_context/query_memory/search_memory all perform retrieval; read_messages/poll_messages/tail_messages/read_message_range all read session messages; session_end/end_session and save_finding/save_finding_auto are near-duplicates. The deprecated get_observations tool remains exposed, adding further confusion.
Naming Consistency3/5
Most tools follow a readable snake_case verb_noun pattern like create_session, list_findings, and send_message. However, there are notable deviations: noun-only names (health, topic_context, session_recap, session_statistics, memory_timeline), inconsistent ordering (sessions_summary vs get_session_state), and legacy names like get_observations marked deprecated.
Tool Count1/5
76 tools is far beyond even the 50+ extreme threshold, despite spanning several subdomains. Many tools are redundant or deprecated, making the count feel bloated rather than comprehensive.
Completeness3/5
The tool surface broadly covers knowledge library, session memory, collaboration, and Co-Scientist workflows. However, there is no update_finding tool even though several descriptions explicitly instruct agents to 'update' existing findings instead of creating duplicates, creating a dead-end in the core knowledge workflow; artifact update/delete are also absent.
Average 4.2/5 across 62 of 76 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- Last stable release on May 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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 implies a read operation via 'Get' and 'current synthesized state,' but it does not state whether this call has side effects, whether it can trigger generation/verification, or how it behaves for missing, incomplete, or still-running runs.
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 compact, starts with a one-sentence purpose, and uses scannable bullets for triggers. The parameter line mostly restates the schema, but there is no padding and the structure is 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?
This is a simple one-parameter tool with no output schema, so the description is the only source of behavioral and return context. It covers primary triggers but leaves the report's structure and content ambiguous, and it does not distinguish this tool from report-generation/evaluation siblings enough for an agent to confidently prepare a final summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter, run_id, and the description adds 'Co-Scientist run ID.' That is minimal semantic context beyond the schema's 'Run Id' title, but with 0% schema description coverage, the description does not adequately compensate by explaining the ID's format, source, or how to obtain it.
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 identifies a specific verb and resource: get the current synthesized state of a Co-Scientist run. This is more precise than a vague purpose, though it does not explicitly compare itself to sibling tools like create_co_scientist_final_report or evaluate_co_scientist_run.
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 'AUTOMATIC TRIGGERS' section lists concrete cases for calling this tool: inspecting generation and verification progress, checking hypothesis reports, and preparing a final summary. This is clear guidance for when to use it, but it does not mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only claims 'Auto-ingest' and 'NO manual logging needed', revealing nothing about side effects, required git access, data persistence, permissions, or error behavior. It reads as a value statement rather than a behavioral specification.
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 short and front-loads the core action in the first sentence. The second sentence is somewhat redundant with 'Auto-ingest' but is brief and not bloated, earning its place as a clarifying emphasis. Brevity is fine, though it sacrifices substance.
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 three parameters, no output schema, and no annotations, this is insufficient. An agent cannot determine how time_window_hours affects ingestion, what include_uncommitted covers, what session_id should reference, or what side effects to expect after the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it mentions none of the three parameters. The meanings of session_id, time_window_hours, and include_uncommitted are left entirely to inference from names and defaults, adding no semantic value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('ingest') and a concrete resource ('session activity from git history'), making the tool's function immediately clear. It also differentiates itself from sibling tools like log_observation and save_finding_auto by its unique source (git history), even without naming them.
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 phrase 'NO manual logging needed!' implicitly positions this tool as the automated alternative to manual logging, suggesting when it might be used. However, it gives no explicit conditions, prerequisites, or comparison with specific sibling alternatives, leaving usage context mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose useful behavior: FTS5 full-text search, optional status filtering, a default limit, and relevance-ranked results. However, it does not explain what a matching session consists of, how results are shaped, or any pagination or failure 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 well-structured and front-loaded: a one-sentence purpose, mechanism, compact Args list, and Returns line. Every sentence earns its place, and there is no redundant filler.
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 four parameters, no output schema, and no annotations, the description is too incomplete for reliable invocation. It does not mention the required agent_id parameter, does not describe the return dict structure beyond 'ranked by relevance', and offers no guidance against sibling session/search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only parameter documentation. It adds helpful context for query (FTS5 syntax), status (optional), and limit (default 20), but it completely omits agent_id, which the schema marks as required. This is a critical gap that would leave an agent uncertain what to supply.
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 a specific action and resource: 'Search across all sessions by message content.' It distinguishes this from sibling search tools at a high level (sessions vs memories/findings), though it does not explicitly name or differentiate any alternative.
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 intended use is implied by 'Search across all sessions by message content' and the FTS5 reference, but the description gives no explicit guidance on when to prefer this tool over sibling search tools like search_memory, search_findings, or query_memory. No exclusions, prerequisites, or when-not-to-use cases are provided.
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?
Since no annotations are provided, the description carries the full burden. It discloses the tool's return contents and optimized format, which is helpful. But it does not state whether this is a read-only operation, mention side effects, or explain behavior around empty sessions or missing artifacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is front-loaded and useful. However, 'PRIMARY tool', 'GO-TO tool', and the repeated WORKFLOW POSITION section are redundant. The trigger bullets and workflow position overlap enough that some sentences do not earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers triggers, return content, and parameter semantics sufficiently for a simple read-style context tool. But there is no output schema, no annotations, no behavior around stale/missing state, and no guidance on how this tool relates to siblings like check_context or session_statistics. The default value mismatch also reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains all three parameters in plain language, which is important because schema description coverage is 0%. However, it states max_messages default is 20 while the schema states default is 5. This conflicting default can mislead an agent into assuming different behavior, so the parameter guidance is partially inaccurate.
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 states a specific verb and resource: 'Get a compiled context view of the session.' It also clarifies what is returned (summary, messages, state, tasks, artifacts) and claims PRIMARY status. It does not explicitly differentiate against close siblings such as check_context or get_session_state, but the compiled-view framing is distinct enough.
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 AUTOMATIC TRIGGERS and WORKFLOW POSITION guidance, telling the agent when to call it: after joining, before starting work, after task assignment, and when unsure. It gives strong context but no when-not-to-use statements or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full behavioral disclosure burden. It implies a read-only comparison operation, but does not describe the output format, return value, side effects, or any data requirements beyond accepting result dicts.
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 cleanly structured: purpose, automatic triggers, parameter. Every line contributes useful information and the decision contexts are front-loaded with no filler.
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?
Since there is no output schema and no annotations, the description should clarify what the tool returns or how the comparison is presented, but it never does. It gives enough trigger information for selection, but not enough for an agent to know what to do with the result.
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 only says 'array of objects' with 0% coverage, so the description adds useful meaning by distinguishing workflow result dicts from pre-evaluated result dicts. However, it does not specify the expected keys or what distinguishes a raw result from a pre-evaluated one, so compensation is only partial.
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?
States a specific verb ('Compare') and resource ('benchmark results across workflow types'), and enumerates the three workflow types involved. This clearly distinguishes it from sibling tools like evaluate_co_scientist_run or get_co_scientist_benchmark_tasks.
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?
Provides explicit automatic trigger conditions, including the decision context of whether the simpler workflow should remain default. It lacks explicit when-not-to-use guidance or named alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. 'Get details' implies a read-only operation, and the note to 'see the plan and rules before using' hints at additional context, but the description does not explain return format, side effects, or prerequisites in concrete terms.
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 organized into a clear summary sentence, a trigger list, and a parameter note. It is concise and front-loads the core purpose, though the instruction to 'see the plan and rules before using' is somewhat vague and could be more actionable.
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 tool with one required parameter and no nested objects, the description covers invocation and typical use cases well. However, there is no output schema and the description does not describe what the returned template details look like, which is a noticeable gap for an agent deciding whether this tool meets its need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the schema only provides the title 'Template Id' for the required parameter. The description compensates by defining template_id as a template identifier and supplying concrete examples like 'deep_research' and 'code_review', adding value 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 that the tool 'gets details of a specific session template,' identifying both the action and the resource. It distinguishes itself from list-oriented siblings like list_templates by emphasizing 'specific,' but it does not explicitly name or contrast a sibling tool.
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 an 'AUTOMATIC TRIGGERS' section with concrete cases: reviewing a template before creating a session, checking tasks in a template's plan, or responding to user questions about a specific template. It gives clear guidance on when to use the tool, though it does not mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It implies a read-only search over artifact content and scopes the search to a session, which is helpful. However, it does not disclose what is returned, whether matching is case-sensitive, whether metadata is included, or any rate or access limitations.
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 well-structured with a one-line purpose, a trigger list, and a parameter list. It is concise and scannable, though there is minor redundancy between 'Search artifact content by keyword' and 'Find saved work by topic or term'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, triggers, and parameter semantics, which is strong for a search tool. However, it lacks information about the return format or result contents, and does not clarify how this tool differs from related search tools such as search_knowledge or grep_messages. Given no output schema exists, some return-behavior guidance 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?
Schema description coverage is 0%, but the description compensates with a 'PARAMETERS' section that explains each parameter: session_id is 'Session to search', pattern is 'Search term (use simple keywords)', agent_id is 'Your agent ID', and created_by is an optional creator filter. This adds practical meaning beyond the raw 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 opens with a specific verb and resource: 'Search artifact content by keyword' and clarifies it finds 'saved work by topic or term'. This clearly explains what the tool does, though it does not explicitly differentiate itself from sibling search tools like search_findings or search_knowledge.
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 'AUTOMATIC TRIGGERS' section gives concrete call conditions: when looking for artifacts mentioning a topic, needing prior analysis, or searching across saved work products. This provides clear context for when touse the tool, but it does not state when not to use it or name preferred alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the retrieval (read) nature and the constraint that agent_id must belong to the session, which is useful. However, it does not mention error behavior, access requirements, or return shape—gaps that would help an agent anticipate edge cases.
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 organized into clear sections—purpose, triggers, workflow, and parameters—with a one-line summary up front. Every section contributes useful information, and there is no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with three required string parameters and no output schema, the description is sufficiently complete: it states what the tool does, when to call it, and what each parameter means. It stops short of describing the response format or error conditions, but those are less critical for this straightforward retrieval 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?
Schema coverage is 0%, and the description compensates by explaining all three parameters: session_id as the containing session, artifact_id with a concrete example format, and agent_id with a membership constraint. This adds meaningful guidance beyond the bare parameter titles in 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 states a clear verb and resource: 'Get the full content of a specific artifact' and clarifies that artifacts are saved analyses or reports. It does not explicitly differentiate from siblings like get_finding, but the scope is specific enough that an agent can understand what the tool does.
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 'AUTOMATIC TRIGGERS' section lists three concrete conditions for calling the tool, and the 'WORKFLOW POSITION' section provides ordering guidance relative to list_artifacts. It lacks explicit when-not-to-call or alternative tool routing, but the trigger list gives clear 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 only says the tool returns 'pre-filtered best choices,' but does not clarify whether this is a read-only operation, what the result format looks like, whether it reflects real-time availability, or whether any side effects or prerequisites exist. For a simple retrieval tool this is thin.
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 well-structured with a one-line summary, automatic triggers, task types, and a parameters note. It is easy to scan and front-loads the core purpose. Slight redundancy exists between 'Get recommended' and 'Pre-filtered best choices' and between the first trigger and 'User asks for model recommendations,' but it remains tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single required parameter, no annotations, and no output schema. The description explains what the tool does and what input to provide, but it does not describe the return shape or what the agent should do with the results, such as whether it returns model IDs, names, or full metadata. This leaves an agent guessing about downstream use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter title 'Task Type' with no description, so the description must compensate. It does so by explaining task_type as 'What the model will be used for' and listing valid values: research, coding, analysis, writing, summarization, orchestrator, worker. This adds meaningful guidance beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get recommended OpenRouter models for a specific task type.' It clearly differentiates this from sibling tools like list_models by framing it as pre-filtered recommendations rather than a full catalog browse. The listed task types further anchor what the tool covers.
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 an explicit 'AUTOMATIC TRIGGERS' section with concrete scenarios such as 'What model should I use for X?' and 'Choosing models for a session without browsing the full catalog.' It gives clear context for when to call, though it does not explicitly mention when not to call or name alternative tools such as list_models.
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 behavioral transparency burden. It usefully discloses that artifacts are stored as files with metadata indexed in SQLite and that shared=True saves to a shared directory. However, it does not mention overwrite behavior, return value, idempotency, or potential failure modes, which would be valuable for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for triggers, workflow position, and parameters, making it easy to scan. There is minor redundancy between 'AUTOMATIC TRIGGERS' and 'WORKFLOW POSITION', but overall each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for an agent to decide when to use the tool and how to fill parameters. It lacks output schema information and does not clarify the relationship with save_finding, but for a save operation the provided details are largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. All seven parameters are listed with concise but meaningful explanations, including artifact_type examples and the effect of shared=True. This adds value beyond the raw 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 tool saves a research artifact (finding, analysis, summary) to the session, with specific examples and automatic trigger conditions. It is unambiguous about the action and resource, though it does not explicitly distinguish itself from the sibling save_finding tool.
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 explicit trigger conditions for when to call the tool, including completing significant analysis, writing important code/documentation, and saving detailed analyses. It also gives a clear exclusion ('not for inline messages'), though it does not mention alternative tools like save_finding for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the key side effect: ending the session automatically generates a 'compressed summary of all observations' and persists knowledge. However, it does not state whether the session becomes permanently inaccessible, whether the summary is returned, or any other consequential behavior beyond 'end' and 'summarize'.
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 well-structured with 'AUTOMATIC TRIGGERS' and 'WORKFLOW POSITION' sections, making the key guidance easy to scan. There is mild redundancy between 'ALWAYS CALL THIS when ending work' and 'Last tool to call when finishing work', but nothing is wasted.
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 one-parameter terminal action with no output schema, the description covers the purpose, the parameter source, the timing, and the automatic summarization behavior. The only real gap is not describing what happens after the tool returns, but the low complexity and clear workflow position keep this from being a significant omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the sole parameter. It does: 'session_id: The session to end (track this from session_start)' adds provenance and clarifies the value needed. It stops short of format or validation details, but for a single required string parameter this is adequate.
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 states a specific verb and resource: 'End the current session' and trigger automatic summarization, which goes beyond the tool name. It does not explicitly differentiate from the similarly named sibling 'end_session', but the automatic-summarization behavior provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit trigger conditions ('User indicates they're done', 'Session goal has been achieved', 'About to start unrelated work') and workflow positioning ('Last tool to call when finishing work'). It lacks explicit when-not-to-use or alternative-tool guidance, but the usage context is concrete and actionable.
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 of behavioral disclosure. It implies a read operation by saying 'Get detailed statistics', but it never explicitly states that the tool is side-effect-free, what happens when the agent_id does not belong to the session, or whether there are rate limits or data-freshness concerns. The only behavioral constraint is the parenthetical 'must belong to the session'.
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 well-structured with trigger bullets, an output summary, and parameter notes, but it has some redundancy: the fragment 'Messages, agents, artifacts, and timing' is essentially repeated by 'Includes message counts, breakdown by type and agent, artifact count, and time range.' Still, the overall length is reasonable and the key information is easy to scan.
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 two-parameter read-style statistics tool with no output schema, the description covers the essential inputs, the membership constraint, and the main return categories. It does not describe exact output structure or failure behavior, but those are not critical enough to make the description incomplete for basic 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?
Schema description coverage is 0%, and the schema only provides property titles 'Session Id' and 'Agent Id'. The description compensates by explaining that session_id is the session to get statistics for and agent_id is the caller's ID that must belong to the session, adding meaning and a constraint beyond the bare 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 tool gets detailed statistics for a session and enumerates the included dimensions: messages, agents, artifacts, and timing. It is specific enough to understand what the tool does, though it does not explicitly differentiate itself from overlapping siblings like sessions_summary or session_recap.
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 AUTOMATIC TRIGGERS section gives concrete example queries and use cases, such as 'How active was this session?' and comparing sessions by message volume. It provides clear when-to-use guidance, but it does not mention when not to use this tool or identify alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses key behaviors: artifacts are preserved, the session can be exported, and export_to_library should follow termination. It also restricts invocation to the orchestrator, giving the agent important side-effect and authorization context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and well-structured, but it contains redundancy: 'Orchestrator only' appears twice, and the trigger bullets overlap in meaning. It is informative but not as tight as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers the essential context: when to call, who may call, artifact preservation, workflow position, and the follow-up export step. It does not describe error behavior or what happens if a non-orchestrator calls it, but the core guidance is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate; it does list all three parameters with short definitions. However, 'session_id: Session to terminate' is tautological, and while orchestrator_id and summary gain some meaning, the descriptions remain minimal and add no format or constraint 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 tool's purpose with a specific verb—'Terminate and complete a collaboration session'—and adds role and workflow context that distinguish it from more general session tools. It does not explicitly differentiate from sibling names like end_session or session_end, which keeps it from a 5.
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 'AUTOMATIC TRIGGERS' section explicitly lists conditions for calling, and the 'WORKFLOW POSITION' entry places it as the final step before export. It does not name alternatives or say when not to use it, but the context is clear enough for most agents.
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 useful state information ('completed or in-progress') and the kinds of metrics measured, but it does not state whether evaluation is read-only, whether it persists anything, or what it returns. This leaves important behavioral traits unstated.
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 well organized with a one-line purpose, a scannable trigger list, and a parameter list. It is longer than strictly necessary because the parameter section duplicates schema information, but that duplication is justified by the need to add semantics.
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 five-parameter tool with no output schema and no annotations, the description covers triggers and parameter meanings but omits return value/format, side effects, and prerequisites such as whether the run must already exist. The overlap with compare_co_scientist_workflows also leaves a selection gap. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully with a PARAMETERS section that explains each field: run_id as the run identifier, token_count/cost_usd as optional resource usage, human_edits_needed as report edit count, and expert_accepted as a user/expert acceptance flag. This gives clear meaning beyond the bare schema titles.
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 opening sentence names a clear verb and resource ('Evaluate a completed or in-progress Co-Scientist run') and the trigger bullets specify measurable goals such as traceability, citation coverage, and cost. However, the third trigger, 'Comparing the two-session workflow against simpler baselines,' overlaps with the sibling compare_co_scientist_workflows, so the description does not fully distinguish itself from that alternative.
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 explicitly provides 'AUTOMATIC TRIGGERS - Call this when' with three concrete scenarios, giving clear context for invocation. It does not state when not to use the tool or point to an alternative for comparison, so it misses exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the dual-mode behavior and the return type ('Dict with tool descriptions and usage information'), which is helpful for a non-destructive help tool. But it doesn't cover what happens with an invalid tool_name, whether output is markdown or plain text, or any error 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 tightly packed and front-loaded: a one-sentence purpose, two short usage-mode lines, then compact Args/Returns sections. Every sentence earns its place, and the examples make it actionable without bloat.
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 tool with one optional parameter, no annotations, and no output schema, the description is largely complete: it explains both invocation modes, the parameter semantics, and the return shape. Minor gaps remain, such as behavior for an unknown tool name and the display format of the returned help, but nothing critical to a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: it names the parameter, marks it optional, explains its effect, and gives concrete examples ('save_finding', 'create_session'). It stops short of explaining invalid-name handling or case sensitivity, but for a single optional parameter the meaning is well conveyed.
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 states a specific verb and resource: 'Get help about all OpenLMlib MCP tools or a specific tool.' It clearly identifies the two operation modes (no-arg summary vs. specific-tool detail). However, it doesn't explicitly differentiate from the sibling `help_collab`, so an agent might not immediately know which help tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit call patterns: 'Call this with no arguments to see all available tools' and 'Call with a specific tool_name to get detailed usage instructions.' This is clear contextual guidance for both modes. It doesn't mention alternatives or exclude cases (e.g., when help_collab should be used instead), so the full when/when-not guidance is absent.
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 transparency burden. It conveys that results are compact summaries and that status relates to verification packets, implying a read-only listing behavior. However, it does not describe output shape, ordering, or any limitations.
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 terse and well-organized: a one-sentence summary, a trigger list, and a parameter list. Every section earns its place with no filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool with no output schema, the description covers purpose, triggers, and parameter meaning. It still omits the set of valid status values and any detail about the returned summary fields, which an agent may need to interpret results 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 coverage is 0%, so the PARAMETERS section adds needed context: run_id is identified as a Co-Scientist run ID and status as an optional packet status filter. This surpasses the bare schema titles, but no allowed status values are given, leaving an important semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List compact hypothesis summaries for a Co-Scientist run.' It clearly identifies what the tool returns and the domain, and is distinct from sibling tools like start_hypothesis_verification or submit_hypothesis.
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?
An 'AUTOMATIC TRIGGERS' list explicitly states when to call this tool: inspecting generated hypotheses, selecting for verification, and checking which packets were sent. It does not mention when not to use it or name alternative tools, but the given triggers are concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states that the tool BLOCKS until messages arrive or timeout expires, and explains its role in continuous collaboration. It could add what happens on timeout or whether messages are consumed/destroyed, but the most important behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, but repetitive: 'AUTONOMOUS LOOP tool', 'primary mechanism for agents to run continuous collaboration', and 'WORKFLOW POSITION: Main loop tool' all convey the same idea. The usage pattern is useful, but the text could be tightened without losing meaning.
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 polling tool with no annotations and no output schema, the description covers when to use it, how to use it, the blocking behavior, and all parameters. It lacks explicit details about timeout response behavior and differentiation from read-focused siblings, but overall it provides enough context for an agent to select and call the tool 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 description coverage is 0%, so the description must compensate. It does: all six parameters are listed with concise functional meaning, defaults for timeout and limit, and a special note that timeout=0 means no wait. Some entries like 'msg_types: Filter by message types' are terse, but sufficient for correct invocation.
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 identifies a specific action ('Wait for and read new messages from a session') and clearly frames the tool as the main autonomous-loop communication mechanism. It is unambiguous about what the tool does, though it does not explicitly contrast itself with sibling tools like read_messages or tail_messages, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit trigger conditions: running an autonomous loop, waiting for other agents, and needing real-time collaboration. It also provides a concrete usage pattern with send_message and a repeat loop. However, it does not mention alternatives or state when not to use this tool, so it stops short of full exclusion 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, the description carries the behavioral disclosure burden. It usefully reveals that the result is scoped to sessions the agent joined and is a quick high-level overview, but it does not describe the returned summary's structure, limitations, or behavior when no active sessions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, then provides a clearly labeled trigger list and a parameter explanation. Every sentence contributes useful guidance without repetition.
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 one-parameter, read-only summary tool without an output schema, the description gives enough trigger context, parameter semantics, and scope to let an agent invoke it correctly. It could be more specific about the summary content, but the low complexity makes the current description largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The sentence 'Your agent ID (summary is scoped to sessions you joined)' adds meaning beyond the raw schema by explaining what agent_id is used for and how it affects the result.
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 uses a specific verb and object: 'Get a summary of all active sessions' and adds 'Quick overview of ongoing work,' so an agent can tell it is a lightweight read-only overview. However, it does not differentiate from sibling tools like list_sessions, get_agent_sessions, or session_statistics, which could serve similar purposes.
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 explicit 'AUTOMATIC TRIGGERS' with concrete scenarios, such as when a user asks what sessions are active or before joining a new session. It lacks when-not-to-use guidance or named alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal meaningful behavior: automatic injection of relevant context, loading knowledge from all previous sessions, and returning compressed observations. However, it does not disclose potential side effects like session persistence, whether repeated calls create multiple sessions, or any state changes beyond starting a session.
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 well-structured with clear sections for triggers, workflow position, and parameters. The first sentence is a strong front-loaded definition. It is slightly repetitive ('ALWAYS CALL THIS' and 'WORKFLOW POSITION' say similar things) but overall each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the return behavior is only vaguely described as 'context block with relevant past observations (compressed for efficiency).' It also does not explain how the returned context should be used, what happens when no past context exists, or how this relates to sibling session tools like create_session and end_session. Some gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining all four parameters. session_id is described as a unique identifier, query as the session focus for finding past context, limit as the max observations with a default and tuning advice, and user_id as an optional identifier. This goes well beyond the bare 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 opens with a specific verb and resource: 'Start a new session and automatically inject relevant context from past sessions.' It clearly conveys what the tool does, but it does not explicitly differentiate itself from sibling tools like create_session or join_session, which could overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context through 'AUTOMATIC TRIGGERS' and states that this should 'ALWAYS CALL THIS' at the start of any work session, and positions it as the 'First tool to call when starting work.' It clearly says when to use it, but it does not mention any exclusions or alternatives, such as when create_session might be preferred.
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 of behavioral disclosure. It usefully indicates that the operation runs on a test dataset and measures recall/precision, which conveys an offline evaluation context. However, it does not disclose the output format, whether any files are written, or whether this operation has side effects on configuration or logs.
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 well structured, front-loaded with the core purpose, and uses a scannable trigger list followed by parameter definitions. There is minor redundancy between 'For developers testing improvements' and 'This is a development/evaluation tool, not needed for normal usage,' but the content is otherwise economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no required parameters and defaults for both, the description provides enough information to invoke it: what it does, when to use it, and what the parameters mean. The main gap is the absence of any explicit statement about the return value or output format, which matters more because there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only types and defaults, with 0% description coverage, so the included PARAMETERS section is essential and fully compensates. It clearly defines dataset_path as the path to the JSON test-query file and final_k as the number of results per query to evaluate. This gives the agent enough meaning to invoke the tool correctly.
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 first sentence clearly states a specific action and resource: 'Run retrieval evaluation metrics on a test dataset.' It also adds audience context ('For developers testing improvements') and explicitly positions the tool as a development/evaluation tool rather than normal usage. It does not explicitly differentiate from sibling tools like search_knowledge or evaluate_co_scientist_run, so it stops short 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The AUTOMATIC TRIGGERS section lists concrete conditions under which to call the tool, such as evaluating retrieval quality after configuration changes and measuring recall/precision. The line 'not needed for normal usage' provides a clear exclusion. It does not name an alternative tool to use instead, so guidance is good but not fully explicit.
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 behavioral burden. It discloses useful traits beyond structured data: '~200 tokens/result' (output size/cost), the window behavior, and its 'Layer 2' pipeline position. However, it never states whether the operation is read-only or has side effects, and it offers no failure behavior or rate-limit context; the repetitive phrasing also dilutes the signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The section layout (triggers, sequencing hint, parameters) is well organized and front-loaded with 'Layer 2.' But the same idea is stated three times: 'Get chronological context,' 'Returns narrative flow around observations,' and 'Provides timeline context for how observations relate to each other,' and the trigger bullets partially repeat this as well. It could lose ~30% of its words without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool (2 flat params, 1 required, no output schema, no annotations), the description covers the essentials: purpose, when to invoke it, both parameter semantics, and a result-size hint. The main gaps are the absence of an explicit read-only/no-side-effects declaration and a precise return shape — but the tool's low complexity makes this close to sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate — and it does. It explains ids as 'List of observation IDs from search_memory' (tying the parameter to its upstream source) and window as 'Time window for context around each observation (default: "5m")' (semantics plus default value). Both parameters gain real meaning beyond the bare schema titles 'Ids' and 'Window.'
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 verb+resource: 'Get chronological context for memory IDs' and clarifies the return as 'narrative flow around observations' and 'timeline context.' It distinguishes itself by positioning as 'Layer 2' to be used after search_memory, which separates it from siblings like topic_context, search_memory, and get_observations. An agent can readily tell what this tool does and how it differs from nearby alternatives.
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 'AUTOMATIC TRIGGERS' section gives concrete when-to-use conditions: having observation IDs from search_memory, needing event sequence, or needing temporal relationships. It also gives the procedural hint 'Use AFTER search_memory to understand sequence.' It lacks explicit when-not-to-use guidance or named alternatives (e.g., when to prefer topic_context), so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that this is a creation step and the first action in a collaboration lifecycle, and it gives follow-up guidance. But it does not describe side effects, whether a session identifier is returned, persistence, permissions, or what happens on duplicate/conflicting session creation—so behavioral transparency remains partial.
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 well-structured with clear sections: purpose, automatic triggers, workflow position, parameters, and follow-up. It is slightly longer than strictly necessary—some trigger bullets restate the opening sentence—but each section earns its place and the most important information is front-loaded.
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 no annotations and no output schema, the description should explain what the caller receives after creation, especially a session identifier needed by join_session and send_message. It explains when to call and the parameter semantics, but the missing return/result contract is a meaningful gap for orchestrating the next steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description is the only source of parameter meaning. It compensates well by explaining every parameter: title and task_description are described, plan is defined as 'list of task dicts (step, task, assigned_to)', rules is defined as 'session rules (max_agents, require_assignment)', and created_by is identified as 'Your agent identifier' with its default. This adds substantial semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-object pair: 'Create a new collaboration session for multi-agent research.' It clearly names the resource (collaboration session) and separates this from sibling session tools by emphasizing 'multi-agent research' and positioning it as the first tool in a collaboration workflow.
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 explicitly states automatic triggers ('Starting a new multi-agent research task', 'User asks to set up a collaboration session', 'You need to coordinate work across multiple agents') and workflow position ('First tool in any collaboration workflow'). It also points to the next steps (join_session, send_message). However, it does not explicitly state when not to use this tool, such as when a session already exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it adds useful behavioral context: the operation 'permanently store' and 'Afer a session completes' indicates persistence and timing. However, it does not disclose potential side effects, authorization needs, idempotency, or error behavior, so it only partially covers behavioral transparency.
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 front-loaded with a one-sentence purpose, then organized into trigger bullets, workflow position, and parameter list. It is slightly repetitive ('Afer a session completes' appears twice), but overall each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 params, no output schema, no annotations, and many similar sibling tools (save_finding, save_finding_auto, export_co_scientist_findings), the description covers triggers, workflow position, and params but does not distinguish from those siblings or explain what the call returns. It is adequate but leaves routing and return behavior missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a dedicated PRAAMETERS section explaining the meaning and defaults for all 7 parameters, e.g., 'artifacts_ids: Specific artifacts to export (None = all)' and 'project: Project name for findings (defaults to session title)'. This exceeds the schema, which has 0% description coverage, by adding functional semantics and defaults context.
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 verb and resource: 'Export session artifacts as findings in the main OpenLMLib library.' The explicit mention of session artifacts and main library differentiates it from generic save_finding and export_co_scientist_findings, and the automatic-trigger context reinforces its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'AUTOMATIC TRIGGERS' with conditions like 'A collaboration session is completed' and workflow position 'Afer session termination, before starting new work.' It lacks explicit alternatives or when-not-to-use guidance, hence not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clarifies the core behavior of retrieving a specific finding and implies retrieval of full details, but it does not go deeper into consequences, error behavior, or any read-only guarantees. With no annotations provided, the description carries the burden, yet it mostly restates the operation rather than adding richer 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the core action front-loaded followed by an organized trigger list and a helpful alternative pointer. The trigger bullets are slightly repetitive but each line serves a practical purpose for an agent deciding when to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter fetch tool with no output schema, the description covers the main inputs, when to use it, and how to obtain the required ID. It does not describe the exact return shape, but stating that it provides 'full details' is arguably sufficient for a simple getter, and the guidance to use search_findings fills the main contextual gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'finding_id' with no description, and schema coverage is 0%. The description adds some meaning by indicating the ID comes from search results or list and by telling the agent to use search_findings if the ID is unknown, but it does not describe the ID format or naming convention in any detail.
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 verb and resource: 'Get a specific finding by its ID.' This clearly distinguishes the tool from siblings like list_findings, search_findings, and delete_finding, which have different actions and scopes.
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?
The 'AUTOMATIC TRIGGERS' section explicitly lists when to call the tool, such as when the user references a finding ID or when full details are needed. It also names search_findings as the alternative to use first when the ID is not already available, making the decision logic clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It adds useful behavioral context: relationship detection is based on shared agents or same orchestrator, and the agent_id constraint ('must belong to the session') is disclosed. However, it never states whether the operation is strictly read-only, what the return payload looks like, or how errors surface (e.g., agent_id not belonging to the session).
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?
Well-structured and front-loaded: one-line summary, trigger list, mechanism sentence, parameter list. Minor redundancy between the opening summary and the closing mechanism sentence, but every section earns its place and nothing is bloated.
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 2-param, no-output-schema, no-annotation tool, the description covers purpose, when-to-call, mechanism, and parameter constraints. The only notable gap is the absence of any description of the return value/format, which matters more since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates with a PARAMETERS section: session_id is defined as the 'base session' and agent_id as 'your agent ID (must belong to the session)', adding real meaning beyond bare property names. Not a 5 because it doesn't explain ID formats or elaborate on the orchestrator concept.
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?
States a specific verb+resource ('Find sessions related to a given session') and adds the distinguishing mechanism ('based on shared agents or same orchestrator'). This clearly separates it from siblings like session_context, session_statistics, or search_sessions, which target a single session or a search-return.
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?
Provides an explicit AUTOMATIC TRIGGERS block with concrete trigger phrases ('What other sessions is this related to?') and scenarios (prior work by same team, shared agents/orchestrator). Lacks when-not-to-use or named alternatives, so it stops shy of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it does disclose core behavior: persisting a packet, letting run state index it, and avoiding copying large JSON into chat. It does not, however, describe success/failure responses, idempotency, or side effects for invalid packets, so transparency is partial.
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 front-loaded with the purpose and then organized into trigger, workflow, and parameter sections. It is slightly repetitive across the trigger bullets—persist, index, and before verification all point to the same submission action—but no sentence is wasted.
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 three-parameter submission tool with no output schema, the description covers what the tool does, when to call it, where it fits in the pipeline, and what each parameter means. It omits return-value and failure-mode details, but the operational context is sufficient to use 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 description coverage is 0%, so the description must compensate. Its PARAMETERS section defines all three parameters: run_id as the Co-Scientist run ID, hypothesis_packet as a JSON-compatible packet, and created_by as an optional agent/model ID. This is meaningful beyond the schema's bare titles, though it does not detail the packet's internal structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence uses a specific verb ('Submit') with a precise resource ('validated hypothesis packet') and target ('Co-Scientist run'). The qualifier 'validated' and the workflow reference to validate_hypothesis_packet distinguish it from sibling tools like submit_verification and start_hypothesis_verification.
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 includes an explicit 'AUTOMATIC TRIGGERS' section with three concrete conditions and a 'WORKFLOW POSITION' statement specifying use during the generation phase after validate_hypothesis_packet passes. It does not explicitly name alternatives for later stages, such as submit_verification, so it lacks a full when-not/alternatives statement.
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 must carry the behavioral disclosure burden. It does disclose that this is a persistence operation and mentions what gets persisted (verdict, confidence, evidence, tests, citations). However, it does not explain what happens on duplicate submissions, whether it overwrites, or what the response/error behavior is. The 'one-report-per.hypothesis' phrase gives a hint but not full 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 well-organized with a clear purpose line, trigger bullets, and a parameter list. It avoids filler and front-loads the most important information. Every section earns its place, especially given the zero schema description coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool sits in a complex Co-Scientist workflow with many related siblings, and it haas no annotations or output schema. The description explains when to call it and what the main parameters are, but it does not clarify the expected internal shape of verification_report, the relationship to start_hypothesis_verification, or behavior on duplicate submission. These gaps make it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaningful one-line semantics for all four parameters: run_id, hypothesis_id, verification_report, and created_by. It also hints at the report contents in the trigger bullets. It doesn't specify exact fields within the verification_report object, but it gives enough context for an agent to understand the param roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Submit a verification report') and a specific resource ('one Co-Scientist hypothesis'). It also names the one-report-per-hypothesis constraint, which helps distinguish it from related tools like start_hypothesis_verification or submit_hypothesis.
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 'AUTOMATIC TRIGGERS' section gives concrete conditions for when to call this tool: after a verification agent adjudicates a hypothesis, when persisting verdict/evidence/citations, and when completing the one-report-per-hypothesis handoff. It lacks explicit 'when not to use' guidance or named alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the gating nature, return shape (valid status, issue count, actionable issues), and what to do on valid=False. It does not explicitly state 'no side effects,' but the 'before saving' and 'before verification' framing strongly implies it is a non-mutating check.
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 organized with clear headings and bullet triggers, and the core purpose is front-loaded. Minor redundancy exists between the opening sentence, the trigger list, and WORKFLOW POSITION all repeating 'before verification,' but the structure is still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter validation tool with no output schema and no annotations, the description covers purpose, when to call, workflow position, parameter, and return semantics. It is missing exact response fields and packet schema details, but those are partially covered by the gating rationale and sibling tools.
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 coverage is 0%, so the description must compensate. It identifies the packet as a 'JSON-compatible hypothesis packet object' and hints at the relevant fields via missing citations, evidence, lineage, or scores. However, it does not specify the packet structure or required fields, leaving the agent to rely on get_hypothesis_packet_schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Validate a Co-Scientist hypothesis packet before verification.' The automatic triggers and workflow position ('Gate every packet before verification') make its role distinct from siblings like start_hypothesis_verification or verify_co_scientist_citations.
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 explicit AUTOMATIC TRIGGERS with concrete call conditions (generation agent proposes, before saving, before sending to verification, need actionable errors) and a clear workflow position. It does not explicitly name when-not-to-use or alternative tools, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses that this creates a session and that the resulting session contains a structured plan plus rules, which goes beyond a generic create verb. However, with no annotations at all, it does not address behaviors such as whether creation is idempotent, what happens if the template id is invalid, or what the response contains. The core side effect is clear, but the full operational burden is not covered.
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 compact and well structured with a one-line summary, trigger bullets, workflow positioning, and a parameter list. There is almost no filler, and the most useful routing information appears near the top. The parameter list duplicates schema names but adds value through examples and defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool, it gives enough to make a reasonable call with known templates and example values. But it does not mention what the tool returns, how to discover valid templates, or what happens on failure. Given no output schema and no annotations, a sentence pointing to list_templates or describing the returned session would make this materially more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the parameter list in the description is the main semantic source. It describes every parameter, gives example values for template_id, and notes the default for created_by. The main limitation is that it does not point to list_templates or get_template for discovering valid template identifiers or explain constraints on title and task_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 action: creating a session from a predefined template, and distinguishes it from create_session by emphasizing the structured plan and rules. The examples of common workflows reinforce the purpose. This is a specific verb+resource pairing, not a tautology.
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?
The description provides explicit automatic triggers with concrete conditions for when to call this tool, such as when the user asks for a template session or when a pre-built plan is preferred. It also names create_session as the alternative and gives the workflow-selection criterion: use this when a structured plan is desired. This gives clear guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does a good job: it discloses that the tool saves a summary, optionally searches for findings to persist, prevents knowledge loss, and returns session end status and export results. It does not discuss reversibility or potential side effects on related data, but the key behaviors are transparent.
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 well-structured and front-loaded with the core purpose, followed by triggers, workflow position, parameters, and return value. There is minor redundancy ('ALWAYS call this when user indicates work is done' partly repeats the first trigger bullet), but overall every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a composite tool with no output schema and no annotations, the description supplies triggers, workflow position, parameter guidance, and return behavior, which is sufficient for an agent to select and invoke it. It could be more complete with failure modes or a clearer contrast against session_end, but the core context is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does: session_id is tied to start_research or session_start, export_to_library explains its conditional effect and default, and project is described as optional. Each parameter receives semantic meaning beyond the raw 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 tool ends the current session with automatic knowledge preservation and calls out that it is a composite tool. It distinguishes itself by combining session_end with artifact export, but does not explicitly contrast with siblings like terminate_session or leave_session.
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?
Provides explicit trigger conditions ('User indicates work is done', 'Research or analysis is complete', 'About to start unrelated work') and workflow position ('Last tool in any research/analysis workflow'). However, it lacks guidance on when to use an alternative such as terminate_session, leave_session, or session_end instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. The verb 'Get' and the repeated 'Returns' strongly imply a read-only operation, and the return-content summary is useful. However, the description never directly states that this call has no side effects, requires no special authorization, or is safe to invoke at any time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a one-line purpose sentence, three concise trigger bullets, one workflow-position line, and a short return summary. Every sentence earns its place and no padding is present.
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?
There is no output schema, so it is important that the description names the returned categories, which it does. It also clarifies when and where to call the tool. It stops short of detailing the exact structure or format of the policy items, but for a zero-parameter, low-complexity policy lookup, the coverage is adequate.
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 is an empty object with zero parameters, so there is no parameter ambiguity for the agent to resolve. This meets the zero-parameter baseline, and the description adds useful context by summarizing what the returned policy will contain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with an unambiguous verb+resource pairing: 'Get the Phase 0 Co-Scientist scope and safety policy.' It also enumerates the exact output content (accepted domains, blocked domains, approval-required actions, Phase 0 limits) and provides a workflow position, making it easy to distinguish from siblings like screen_co_scientist_scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit 'AUTOMATIC TRIGGERS' with three specific conditions and a 'WORKFLOW POSITION' note. It does not explicitly state when not to use the tool or name alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It does state the joining action and gives follow-up steps ('read the session_context above... then use read_messages'), but it does not disclose side effects such as whether joining mutates the session participant list, whether it is idempotent, or what happens with invalid session IDs.
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 well-structured with clear sections: purpose, automatic triggers, workflow position, parameters, and next steps. Every sentence adds operational value, and the core action is front-loaded. There is no redundant or filler text.
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 3-parameter tool with no output schema, the description gives a complete invocation recipe: when to call, why, what parameters to provide, and what to do after joining. It does not explicitly describe return values or side effects, but these are not covered by an output schema and the join action is reasonably self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It does so effectively: session_id is 'ID of the session to join', model is shown with examples, and capabilities is marked as optional with an example array. It does not explain the impact of capabilities on the session, which prevents a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Join an existing collaboration session as an agent.' This clearly distinguishes it from sibling tools like create_session, leave_session, list_sessions, and read_messages without requiring schema inspection.
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 explicit AUTOMATIC TRIGGERS ('assigned work', 'need to participate', 'starting work as a worker or specialist') and a WORKFLOW POSITION ('after session is created and you have the session_id'). It gives clear context for when to call, though it does not explicitly state when not to call or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It discloses meaningful behavior: automatic 3-layer progressive retrieval, fast search, expansion of high-confidence hits, and chronological context for the periphery. It does not explicitly state the absence of side effects or describe the exact output shape, but it is far from opaque.
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 well-structured with trigger bullets, a short algorithm explanation, and a parameter list. It is readable and front-loads the key replacement fact. Some minor redundancy exists between the opening phrase and the later algorithm description.
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 absence of an output schema, the description leaves the return format only vaguely implied ('expands...', 'provides chronological context'). It also does not help the agent choose among several closely related memory/retrieval siblings beyond search_memory. Triggers and parameters are covered, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does: 'limit' is clarified as an internal fetch limit, and 'filters' comes with a concrete example. 'query' is only restated as 'Search query', so not every parameter gets equally substantive semantics.
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 labels the tool as an auto-expanding retriever for memory and states its function: searching observations from past sessions and retrieving context on a topic. It also distinguishes itself from a sibling by explicitly declaring it 'REPLACES search_memory'.
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 provides explicit automatic trigger conditions ('Call this when...') for the two main use cases. It also alerts the agent that this tool replaces search_memory, which gives clear selection guidance for that sibling, though it does not contrast with other related memory/retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add meaningful behavior: the default top_k fallback, the handoff artifact/message concept, and the note about avoiding copying the full transcript. However, it does not disclose side effects such as whether this creates a persistent artifact, whether the verification session is asynchronous, or whether any prior state is overwritten. There is no contradiction with annotations, but the behavioral disclosure is incomplete.
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 well-structured with clear sections for triggers, workflow position, and parameters. The first sentence delivers the core purpose efficiently. Some minor redundancy exists between the trigger bullets and workflow position, but overall each section serves a distinct and useful role without excessive padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential invocation details: when to call, what parameters to use, and the default behavior. It is missing only a clarification of what the tool returns or confirms after the handoff, but for a transfer-style action this is a minor gap rather than a critical one. The description is sufficient for an agent to select and call the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate, and it does. The dedicated PARAMETERS section explains each of the four parameters in plain language and clarifies the relationship between hypothesis_ids and top_k. It also provides the practical detail that omitted hypothesis_ids triggers top_k-based selection, which the raw schema does not convey.
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 and resource: 'Send selected Co-Scientist hypotheses to the verification session.' It clearly distinguishes the tool from related siblings by naming the conceptual 'verification session' and by referencing the workflow with submit_hypothesis. This leaves no ambiguity about what the tool accomplishes.
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 'AUTOMATIC TRIGGERS' section explicitly lists when to call the tool, and the 'WORKFLOW POSITION' states that it should be used after submit_hypothesis has indexed at least one packet. It also explains the default selection behavior when hypothesis_ids is omitted. It lacks explicit when-not-to-use guidance or named alternatives, but the context is strong enough for correct routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It clearly frames the operation as one of checking citations against sources, but it does not disclose return format, failure behavior, side effects (e.g., network fetches or local file reads), or whether the operation is strictly read-only. This leaves moderate uncertainty in behavior.
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 well structured with a brief purpose statement followed by bullets and concise sections; the trigger list is slightly repetitive with the purpose but earns its place as usage guidance. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter verification tool the description includes purpose, triggers, workflow position, and parameter semantics. However, there is no output behavior or return-value description, and no annotations, so the agent is left to guess what the tool returns after verifying citations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining citations are a non-empty list and session_ids scopes artifact lookup. It adds the non-empty constraint and the semantic role of session_ids, which is beyond the bare property names, though it does not specify citation string format.
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?
States a specific action: verifying Co-Scientist citations against three concrete target types (URLs, artifacts, local files). The workflow-position references to start_hypothesis_verification and submit_verification distinguish it from those verification-workflow siblings, so an agent can tell it apart.
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?
Provides an AUTOMATIC TRIGGERS section enumerating exact conditions (preflight packet citations, verification report citations before submission, artifact/local-file references) and a WORKFLOW POSITION naming the precise stage between validation and verification/submission. This is explicit enough to route tool choice without needing to open sibling schemas.
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 does disclose the main side effect: it creates two linked sessions in one call and prevents transcript leakage between generation and verification. However, it does not clarify return behavior, whether the workflow runs asynchronously, resource costs, or any permission prerequisites, which leaves the behavioral picture incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses clear section headers, front-loads the core action, and provides concise trigger conditions, workflow placement, and parameter semantics. Every sentence contributes meaningful guidance without extraneous detail.
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 multi-session workflow creation tool, the description covers purpose, triggers, placement, and all parameters. It lacks any mention of return values or follow-up steps, and with no output schema present, that leaves a moderate gap. Still, for selecting and invoking correctly it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must supply parameter meaning, and it does. Each of the four parameters receives a useful explanation beyond type/default information: topic is the research objective, constraints are optional limits or domain notes, created_by identifies the creator, and top_k specifies how many hypotheses go to verification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Create a linked Co-Scientist generation and verification workflow.' It further clarifies scope by stating it creates both generation and verification sessions in one call, cleanly distinguishing it from related tools like start_hypothesis_verification or create_co_scientist_final_report.
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 'AUTOMATIC TRIGGERS' section explicitly states when to call the tool: when a user asks to start a Co-Scientist run, when two linked sessions are needed, or when hypotheses must be generated and verified without transcript leakage. It also notes the workflow position: use after confirming topic scope. However, it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the disclosure burden. It is transparent about filtering behavior ('intentionally skips inconclusive, contradicted, and unsafe/out-of-scope hypotheses') and the destination library. It could still mention duplicates/overwrite behavior or return values, but core side-effect selection is clear.
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?
Well-organized with AUTOMATIC TRIGGERS, WORKFLOW POSITION, and PARAMETERS sections, and the core purpose is front-loaded. The skip/unsupported idea is repeated a couple times, but the overall length is reasonable and every section adds value.
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 moderate-complexity tool with no annotations or output schema, the description covers what it does, when to call it, which parameters to provide, and what it intentionally excludes. Missing return/error details are a minor gap, not a blocker for correct 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?
Schema coverage is 0%, but the PARAMETERS section compensates by explaining each parameter's meaning and optionality ('created_by: Session orchestrator agent_id or model (required)', 'project: Optional...'). This adds practical meaning beyond the bare JSON schema, though run_id could use a bit more format detail.
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?
States a specific action ('Export ... claims into the main knowledge library') and identifies the resource type ('supported Co-Scientist claims') and destination. This wording differentiates it from generic library or finding tools by tying it to Co-Scientist claims and their supported status.
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?
Provides explicit automatic trigger conditions ('A final Co-Scientist report exists...', 'user explicitly asks...') and places it in the workflow ('Use after final report review'). It also tells what will be skipped, but it does not name alternatives or explicitly state when not to use it compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It does so by disclosing important constraints: requesting_agent_id 'Must be same agent id/model identity (own history only)' and agent_id 'matches ephemeral ids via agents.model.' It does not describe return structure or side effects, but as a read-only query this is a minor gap rather than a serious omission.
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 well-structured: a one-sentence summary, a bulleted trigger list, and a compact parameter section. Every section adds decision value, and there is no filler or repetition beyond the acceptable 'Track agent's work history' purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, when to call it, and all parameter semantics, including the own-history restriction. However, there is no output schema and the description does not touch on return format or how the response supports 'continuing work,' so it is not fully complete for an agent needing to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, making the PARAMETERS section essential. The description explains all three parameters meaningfully: agent_id format and ephemeral ID matching, requesting_agent_id ownership restriction, and status filter values ('active', 'completed', 'terminated'). This fully compensates for the bare 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 states a specific action and resource: 'Get all sessions an agent has participated in' and adds purpose 'Track agent's work history.' This is clear, but it does not explicitly differentiate from sibling tools like list_sessions or search_sessions; the agent must infer the distinction from 'participated in' and the triggers.
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 'AUTOMATIC TRIGGERS - Call this when' section lists concrete scenarios: 'what sessions have I been in?', 'Looking for past work by a specific agent', and 'Finding related sessions to continue work.' This provides clear when-to-use guidance but offers no exclusions or comparisons to alternative session-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states that the tool returns a 'JSON-compatible schema description' and clarifies the artifact-first scope of the packet. It also provides workflow context that helps an agent understand the tool's role, though it does not discuss side effects or access requirements, which are less critical for a getter.
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 well-structured with clear trigger lists and workflow positioning, and the main action is front-loaded. It is slightly repetitive with phrases like 'hypothesis packet' appearing multiple times, but every section serves a useful purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description sufficiently explains what the tool returns and when to call it. It could go deeper into what the schema covers, but the tool's entire purpose is to deliver that schema, so listing its contents here would be redundant.
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 zero parameters, so the baseline is 4. There is no parameter-specific meaning to add, and the description correctly focuses on what the schema contains rather than trying to document nonexistent arguments.
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 begins with a specific verb and resource: 'Get the Phase 1 Co-Scientist hypothesis packet schema.' It clearly distinguishes this from sibling tools by focusing on the schema of hypothesis packets rather than validation, submission, or scope policy.
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 AUTOMATIC TRIGGERS section explicitly lists when to call the tool, and the WORKFLOW POSITION adds ordering context ('after scope screening and before saving or sending'). However, it does not mention when not to use it or name alternative tools for related needs, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds meaningful context: FTS5 semantics, OR/AND support, the agent_id membership requirement, a 100-result cap, and msg_types filtering. It does not describe the return format or ordering, which is a moderate gap for a tool without an 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 well-organized into core purpose, triggers, search tips, and parameter notes, with the main purpose front-loaded. It is slightly repetitive around the 'use simple keywords' advice, but each section earns its place and supports correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameters, triggers, and search syntax well, which is strong given no annotations and 0% schema coverage. However, there is no output schema and the description does not explain what the search result looks like, how results are ordered, or how pagination beyond the limit field behaves; this leaves an agent to infer the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate, and it does. Every parameter is explained with practical guidance, including the session scope, simple-keyword advice for pattern, the 'must belong to the session' requirement for agent_id, the default/max for limit, and an example for msg_types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search session messages by keyword' and clarifies the mechanism via FTS5 full-text search. The AUTOMATIC TRIGGERS section further distinguishes this tool from sequence-based message readers by stating it is for when you remember keywords but not the sequence number.
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 AUTOMATIC TRIGGERS section explicitly lists three situations that warrant calling this tool, such as looking for an earlier decision or checking whether a topic was discussed. It provides clear context for when to use it, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the OPENROUTER_API_KEY requirement, one-hour result caching, and force_refresh bypass behavior. The word 'browse' implies a read-only operation, though pagination, rate limits, and exact return format are not mentioned.
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 front-loaded with purpose, followed by a compact AUTOMATIC TRIGGERS block, then requirements and a terse parameter list. Every section earns its place, and there is no filler or redundant prose.
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 tool with no annotations and no output schema, the description covers purpose, triggers, prerequisites, caching, and all parameter semantics. It could be more complete by stating the exact return shape or pagination behavior, and by pointing to siblings like get_model_details for single-model details, but it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's PARAMETERS section fully compensates by explaining all six parameters: search scope, provider examples, combined input+output price semantics, minimum context length, free-only filtering, and cache-bypassing force_refresh. This adds meaning well beyond the raw 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 a specific verb and resource: browse available models from the OpenRouter API, with filtering by provider, price, or context size. It does not explicitly differentiate from sibling tools like get_model_details or recommended_models, but the scope is evident and distinct enough for basic selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit automatic triggers: call when the user asks what models are available, when choosing a model for a collab session, or when comparing pricing/context limits. It does not mention when not to call or name alternative tools, but the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the scope ('sessions you've participated in'), explains the semantic distinction between 'terminated' and 'completed' statuses, and adds the limit maximum of 100 not present in the schema. It implies basic listing behavior by pointing to session_context for details but does not fully describe return format or pagination.
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 well-organized with clear sections for purpose, triggers, and parameters, and the core purpose is front-loaded. It is somewhat longer than strictly necessary because the trigger list contributes to usage guidance more than purpose, but each section earns its place with useful content. Minor redundancy in the first two sentences is acceptable as it clarifies scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description covers the key aspects: what it lists, when to call it, how to filter, and where to get further detail. It doesn't explicitly state the response shape or whether session IDs are returned, but the pointer to session_context implies that. Given the tool's low complexity, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it largely does. It explains the allowed status values and their meanings, and clarifies the limit parameter's maximum, which the schema omits. The only minor gap is not explicitly stating the effect of a null status, though the default null implies no filtering.
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?
States a specific verb and resource ('List collaboration sessions') and narrows scope with 'Browse sessions you've participated in.' The automatic triggers further clarify the tool's purpose, and the scope helps distinguish it from sibling tools like search_sessions or get_agent_sessions even without naming them.
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?
Provides an explicit 'AUTOMATIC TRIGGERS' section listing three clear scenarios for calling this tool, and directs agents to session_context for session details, which is an explicit alternative. However, it does not say when *not* to use this tool or mention alternatives like search_sessions for broader searching, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of indicating safety and side effects. 'List' and 'available' imply a read-only operation and the triggers clarify purpose, but the text never explicitly states that it does not modify state or what the response contains. This is adequate but leaves some behavior implicit.
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 one-line purpose is front-loaded, followed by a compact, scannable trigger list and a useful handoff to create_from_template. Every sentence adds value without redundancy.
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 zero-parameter read-only list tool, the description covers what it does, when to invoke it, examples of the expected workflow items, and the follow-up action. There is no output schema, but the return concept (a list of template names) is self-evident and well supported by the workflow examples.
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 zero parameters, so the baseline is 4 and there are no parameter semantics to document. The schema already exhaustively covers the empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('List available session templates') and clarifies the domain ('Pre-built plans for common research patterns'). It also points to create_from_template as the next step, which implicitly distinguishes listing from creating and from get_template.
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 provides explicit AUTOMATIC TRIGGERS covering the main call contexts: new session planning, explicit template requests, and recommended workflows. It does not explicitly state when not to use it or contrast it with get_template, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavioral impact. It discloses that the tool captures tool outputs, that observations will be 'compressed and summarized for future retrieval,' and that this builds session memory. This gives the agent a clear model of the write side effect and downstream behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and front-loaded intent, but it repeats the same instruction multiple times: 'Call this after significant tool executions' appears in the triggers, workflow position, and general guidance. Some redundancy could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple logging tool with no output schema and no annotations, the description covers purpose, parameters, trigger conditions, workflow position, and post-logging behavior. It does not mention the return value, but for a fire-and-forget observation logger this is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the PARAMETERS section compensates fully by defining every parameter in plain language. It explains session_id as coming from session_start, gives examples for tool_name, and clarifies what tool_input and tool_output represent. This adds meaning well beyond the bare schema titles and types.
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 opening sentence clearly identifies the verb and resource: 'Log an observation from tool execution to build session memory.' This distinguishes it from sibling retrieval tools like query_memory and search_memory, which read memory rather than write it. The purpose is explicit and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit trigger conditions: call when a tool execution produces important or surprising results, when you want to remember what happened, or when building context for a session summary. It also provides a negative guideline: 'Don't log every single tool call - only significant ones with novel insights.' It does not name alternative write tools, but the when/when-not guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states this is a READ OPERATION, requires no confirmation, is safe to call freely, and automatically combines semantic and lexical search with reranking. This is valuable transparency, though it does not mention return format, pagination, or potential edge cases.
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 well structured with clear headings, bold labels, and front-loaded purpose. It is longer than minimal but each section earns its place by providing selection triggers, parameter semantics, and safety context. Minor redundancy exists around the read-operation and safe-to-call messaging.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nine parameters, no annotations, and no output schema, the description does substantial work: it explains the retrieval mechanism, when to call it, parameter semantics, and confirmation status. It is missing return-value details and the date-range parameters, but overall it is sufficiently complete for an agent to select and invoke the tool 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 description coverage is 0%, so the description must compensate. It explains query, project, tags, confidence_min, final_k, and the advanced semantic_k/lexical_k parameters, including defaults and purpose. However, created_after and created_before are not described at all, leaving two parameters without semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run intelligent retrieval combining semantic similarity and keyword matching.' It clearly distinguishes this tool from simple keyword search by highlighting the combined semantic and lexical mechanism, and the AUTOMATIC TRIGGERS section further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use triggers and workflow position: use when keyword search returns insufficient results, for concept/topic exploration, or for a research question. It names search_fts as the alternative, though that exact sibling is not present in the provided sibling list, which introduces slight ambiguity; otherwise the usage guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains message type semantics, broadcast behavior via to_agent=None, the requirement for from_agent, and that system messages are auto-generated. It does not cover delivery guarantees, persistence, or side effects, but for a communication tool the disclosed behavior is reasonably complete.
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 well-structured with clear headers and bullet lists, and most content earns its place. There is some redundancy: message type definitions appear in both AUTOMATIC TRIGGERS and MESSAGE TYPES. Still, the organization aids agent parsing and scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no annotations, and no output schema, the description provides the essential call context: when to use it, what message types exist, and how to fill each parameter. It does not describe the response/return value, which could matter without an output schema, and it lacks alternative routing. However, the core information needed to invoke it correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The PARAMETERS section adds meaning to all six parameters, including broadcast semantics for to_agent, required-ness for from_agent, and listing msg_type values. Some descriptions remain terse (e.g., 'Target session'), but overall it compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Send a message to a collaboration session.' It clearly distinguishes this as the communication/send tool from sibling tools like read_messages, poll_messages, and grep_messages. The 'Core communication tool' framing reinforces its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit AUTOMATIC TRIGGERS listing when to call this tool (assigning work, returning results, asking questions, etc.) and a workflow position ('Use throughout the session for all agent communication'). It does not explicitly state when not to use it or mention alternatives like read_messages for reading, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the approximate response volume (~500-800 tokens), the type of content returned (files, decisions, architecture notes, conventions), and the scope of search (past sessions, optional session filter). It still does not mention potential cost or failure behavior, but for a read-style retrieval tool this is reasonably transparent.
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 well-structured, front-loaded with the core purpose, and uses clear trigger bullets. Each section adds useful information, though a few phrases like 'Deep dive.' and the repeated 'specific topic' could be tightened without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema and no annotations, the description covers the key needs: when to use, what it returns, and what parameters mean. It could be slightly more complete by mentioning what happens when no context is found or how session_id should be formatted, but overall it is well-rounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the input schema. It explains both parameters with examples for topic and clarifies that session_id is optional and defaults to all sessions. It adds real semantic value beyond the raw schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: getting detailed context about a specific topic from past sessions. It adds concrete examples and scopes the tool clearly, making it easy to distinguish from broader retrieval tools. The phrase 'not just compressed tool outputs' further clarifies what this tool uniquely provides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit automatic triggers and states this should be called AFTER session_recap, with concrete example user requests. It does not explicitly name alternatives or say when not to use it, but the trigger conditions are strong enough for an agent to make a good decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden and does a solid job: it states the state is merged, versioned, and uses optimistic concurrency, and gives retry guidance on failure. It also reveals the authorization requirement. It could add response/error details, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with clear sections (purpose, triggers, constraints, parameters), but it repeats 'orchestrator only' twice, which is redundant. The trigger list is useful, but a tighter edit would remove the duplicated constraint.
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?
Covers purpose, triggers, authorization, merge semantics, concurrency, and retry behavior, which is substantial for a 3-parameter tool with no annotations or output schema. It doesn't describe the return value or exact merge depth, so it's not fully complete, but it's enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no descriptions (0% coverage) and only raw types, so the description is the sole source of parameter meaning. It explains session_id as target, state as a dict merged with existing state, and orchestrator_id as the authorization agent ID, adding genuine semantic value for all three parameters.
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?
States 'Update the session state' with a specific verb and resource, and explicitly calls it 'The only way to modify session state,' distinguishing it from read-only siblings like get_session_state. The orchestrator-only constraint further clarifies its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'AUTOMATIC TRIGGERS' list with concrete use cases (recording progress, setting phase, storing metadata) and states a hard exclusion: only the orchestrator may call it. It doesn't name an alternative tool, but 'the only way to modify session state' gives clear selection context among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It indicates a read-only retrieval ('Get') of a 'built-in' and 'fixed' task set, implying no mutation or side effects. This is sufficient for a zero-parameter getter, though it does not describe the return format.
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 definition is compact and well-structured: one clear purpose sentence followed by a focused AUTOMATIC TRIGGERS bullet list. It is front-loaded and every line contributes decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter getter with no output schema, the description adequately covers what the tool returns and when to call it. It could explicitly state the return shape, but the tool's simplicity makes this a minor omission.
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 zero properties and 100% coverage, so there are no parameter semantics to document. The baseline for a 0-parameter tool is 4, and the description adds no unnecessary argument guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get the built-in Phase 9 Co-Scientist benchmark task set.' This clearly identifies what the tool does and distinguishes it from sibling workflow-oriented tools like compare_co_scientist_workflows and evaluate_co_scientist_run.
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 AUTOMATIC TRIGGERS section gives explicit call conditions: setting up benchmarks, needing fixed research tasks for repeatable comparison, and deciding whether Co-Scientist should be the default. It does not provide when-not-to-use guidance or name alternatives, so it falls just short of the top score.
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 behavioral disclosure burden. It discloses deprecation, 'most expensive layer', and that it returns 'complete observation data', which is useful. However, it does not clarify side effects, error behavior, or whether the deprecated tool may be disabled or behave inconsistently.
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 well structured with sections, front-loaded deprecation notice, and a clear trigger list. Slight redundancy exists between 'Get full details' and 'Returns complete observation data', but overall every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter get tool with no output schema and no annotations, the description covers purpose, usage, triggers, cost, and parameter semantics. It lacks explicit detail about the return shape or what happens when called despite deprecation, but the core context needed to use the tool correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain the parameter. It does: 'ids: List of observation IDs from search_memory or memory_timeline' adds provenance and meaning beyond the bare array-of-strings schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Get full details for specific memory IDs', and labels itself 'Layer 3', clearly distinguishing it from search_memory and memory_timeline. It also names query_memory as the replacement, making the tool's role easy to understand.
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?
Provides explicit automatic trigger conditions ('Call this when...'), an explicit exclusion ('Use query_memory instead'), and sequencing guidance ('filter first with search_memory'). This gives an agent clear when-to-use and when-not-to-use 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 burden of behavioral disclosure. 'Get' implies a read-only retrieval, and the description adds context about the returned content ('accepted support/refute/neutral labels', 'deterministic evidence quality levels'). However, it does not explicitly state side-effect-free behavior, auth requirements, or return format, leaving moderate ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a short summary, an 'AUTOMATIC TRIGGERS' section, and a workflow-position note. Every line adds decision-relevant information, and the formatting makes it easy for an agent to scan.
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 parameterless lookup tool with no output schema, the description is complete: it names the artifact, explains its contents, gives explicit trigger conditions, and states workflow position. Nothing critical is missing for an agent deciding to call this tool.
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 takes zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline for a zero-parameter tool is 4, and the description adds useful context about the returned rubric even though no parameters are involved.
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 verb ('Get') and a specific resource ('Phase 6 Co-Scientist evidence labels and quality rubric'). It clearly identifies the artifact being retrieved and distinguishes this lookup tool from mutation or search siblings by focusing on the rubric/criteria artifact.
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?
The description explicitly lists automatic trigger conditions and positions the tool in a workflow: 'Use before writing hypothesis evidence or verification reports that will be promoted to verification.' This gives an agent clear, actionable guidance on when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation via 'Get' and states what information is returned, but it does not explicitly confirm there are no side effects, nor does it mention authentication, rate limits, or what happens for an invalid model_id. This is acceptable for a simple getter but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a brief main sentence, a focused trigger list, a cross-reference to list_models, and a parameter detail section. Every sentence adds value and the most important information is front-loaded. Length is appropriate for the functionality.
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 single-parameter getter with no output schema, the description covers the core use cases, the parameter format, and the relationship to list_models. It could be more complete by describing the exact return structure or error handling, but the tool's simplicity keeps the requirement reasonably low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only specifies that model_id is a string. The description adds the crucial semantic: 'Full model ID' and provides a concrete example ('anthropic/claude-sonnet-4'). This fully compensates for the 0% schema description coverage and prevents an agent from passing a partial or incorrect ID.
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 verb ('Get') and resource ('detailed information about a specific OpenRouter model') and lists the key content (Pricing, context, description). This clearly distinguishes it from list_models, which lists model IDs, while this tool fetches details for one model.
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?
The 'AUTOMATIC TRIGGERS' section explicitly enumerates when to call this tool: when you have a model ID and need full details, when checking pricing/context limits, or when evaluating suitability. It also directs the agent to use list_models first to find model IDs, which is clear guidance on how it relates to a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavior burden. It discloses the tool is a health check and what it returns (database size, finding count, vector index status). The 'Check' wording implies a non-destructive read-only operation, though it does not explicitly state that no mutations occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a clear trigger list, and a short return summary. Every section earns its place, and the most important information 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 zero-parameter diagnostic tool with no output schema, the description fully equips an agent to know when to call it and what to expect back. No critical context is missing.
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 zero parameters and schema coverage is 100%, so there is no param semantic burden on the description. Baseline 4 is appropriate; no param explanation is needed.
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 verb ('Check') and a specific resource ('OpenLMlib database and vector index health'), and further clarifies the tool's purpose with return values. The automatic trigger list makes it clear this is a diagnostic/status tool, distinct from session or context checkers.
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 'AUTOMATIC TRIGGERS' section explicitly lists three concrete situations when to call this tool (debugging, system status queries, verifying initialization). It lacks explicit 'when not to use' or alternatlive mentions, so it does not fully meet the 5-level bar, but provides strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the two behavior modes and states the return type: 'Dict with tool descriptions and usage information.' It does not detail error cases for unknown tool names, but for a help tool this level of transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a clear first sentence, numbered call patterns, an Args section, and a Returns section. Every sentence adds practical value and the front-loaded purpose makes it easy to scan.
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 one-optional-parameter help tool with no output schema, the description covers invocation modes, parameter semantics, and return type. Nothing material is missing for an agent to select and call the tool 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 description coverage is 0%, so the description must compensate for the schema's bare tool_name property. It explains that the parameter is optional, selects a specific tool, and provides a concrete example. This gives the agent enough semantic grounding to use the parameter correctly without enumerating all valid tool names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Get help about all collab MCP tools or a specific tool.' This clearly distinguishes it from sibling help_library (library-focused) and makes the scope immediate. It also clarifies the two main invocation modes, leaving 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to call with no arguments versus with a tool_name, and gives an example ('create_session'). It does not explicitly contrast with help_library, but the 'collab MCP tools' scope and the name handle most of that differentiation. Some exclusion guidance would push this to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It clearly discloses the sanitization behavior and injection-risk avoidance, which is the most important behavioral trait. It does not explicitly state read-only/no-side-effects status or output shape, but 'Retrieve' and the sanitization context cover the primary behavior.
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 front-loaded with the core purpose and then organized into clearly labeled sections for triggers, distinction, error recovery, and parameters. It is scannable and mostly free of fluff, though the trigger bullet list is slightly redundant and 'Use retrieve for raw data' could be worded more precisely.
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 5-parameter tool with no output schema or annotations, the description provides usage triggers, sibling differentiation, a no-results fallback, and parameter semantics. It could add more detail about the return block format and whether tags are comma-separated or repeated, but the essential call-time guidance is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The PARAMETERS section names all five parameters and adds meaningful details: query is required, project/tags/confidence_min are filters, and final_k has a default of 10. It stops short of describing types or formats for tags and confidence_min, so it is not a 5.
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?
States a specific verb and resource: 'Retrieve findings and return them in a sanitized format safe for LLM context.' It also explicitly differentiates from retrieve_findings by contrasting 'sanitized context block' with raw data. An agent can understand what this tool does and how it differs from its closest sibling.
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?
Provides an explicit 'AUTOMATIC TRIGGERS' list with concrete scenarios. It also distinguishes this tool from retrieve_findings and gives a fallback instruction to use search_findings when no results are returned. The only minor ambiguity is 'Use retrieve for raw data,' but context makes clear this refers to retrieve_findings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states behavior beyond schema: no confirmation needed (read operation), mentions performance ('fast'), and explains FTS5 supports boolean operators without defining them in the schema. It does not mention return shape or potential auth requirements, but the read safety is explicitly stated. Since annotations are absent, this fills the gap well.
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 bit longer than necessary but highly organized with sections and bullets. It front-loads the core purpose, then provides actionable triggers, workflow position, and search tips. The extra length is justified by the practical guidance, though some text could be trimmed without loss.
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/search tool, this covers what it returns conceptually, when to use it, and how to craft queries. It doesn't explain the output structure since no output schema, but that is a gap given no return fields are defined. Also does not mention pagination or error cases. Overall sufficient for common use but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the query parameter and gives examples of FTS5 boolean syntax. For limit, it states default 10, which repeats the schema default. It adds semantics for query with advanced operators, but does not fully specify how limit behaves or format of results. This compensates well below 50% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific verb and resource: 'Search findings using keyword (FTS5) search.' It differentiates from retrieve_findings by saying it is fast exact keyword matching, while retrieve_findings is thematic/semantic search. The title is null but description is strong.
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?
Provides AUTOMATIC TRIGGERS with bullet conditions and explicitly says when to use it FIRST, and when to switch to retrieve_findings if results are insufficient. That is explicit guidance with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it delivers: it discloses the read-only safety profile ('CONFIRMATION TIER: READ OPERATION... SAfe to call freely'), the automatic internal routing behavior, and the composite return nature ('combined results from both FTS keyword search and semantic retrieval'). It stops short of describing result ordering or deduplication across the two retrieval modes, which would complete the picture.
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?
Well-structured with labeled sections (AUTOMATIC TRIGGERS, CONFIRMATION TIER, PARAMETERS) and a front-loaded summary sentence. Minor redundancy: the dual-combination behavior is stated in the opening, the routing paragraph, and the closing return sentence. Every section otherwise earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool, the description covers purpose, triggers, routing behavior, safety, parameter semantics, and query strategy. With no output schema present, the main gap is the structure of result items, but for a search tool this is a minor omission given everything else is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverege is 0%, so the description must compensate, and it does: it explains that query accepts 'keywords or natural language' (non-obvious and important for a hybrid-search tool) and that limit means 'Max results.' For a two-parameter tool this is adequate, though it could add detail on whether limit applies per source or in total.
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?
States a specific verb, resource, and method: 'Search findings using both semantic similarity and keyword matching.' It explicitly differentiates from siblings by naming them: 'no need to choose between search_findings and retrieve_findings.' An agent can tell this tool apart from its siblings without opening any schema.
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?
An 'AUTOMATIC TRIGGERS' section lists three concrete trigger conditions, including the tie-breaker 'Not sure whether to use keyword or semantic search.' It explicitly handles the when-not case by routing around search_findings and retrieve_findings, and adds query-strategy guidance distinguishing broad exploration from specific facts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so well. It explicitly declares 'READ OPERATION - No confirmation needed. Safe to call freely,' and it discloses the return behavior: a simple yes/no with finding count and top topics. This is valuable transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded with the core purpose, followed by useful sections for triggers, workflow, safety, parameters, and returns. Minor redundancy exists between 'AUTOMATIC TRIGGERS' and 'WORKFLOW POSITION,' both saying to call at the start of a task, but overall the structure is effective.
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 two-parameter convenience tool with no output schema, the description is complete: it explains when to call it, what it returns, how to supply parameters, and that it is safe. An agent has enough information to invoke it correctly in the intended workflow.
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 0%, so the description must compensate for the lack of parameter documentation. It does provide meaningful semantics for both parameters: query is 'What you're about to work on' and project is 'Filter by project (optional).' The explanations are brief but sufficient for an agent to understand each parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Quick check if relevant context exists before starting work' and 'returns a simple yes/no with relevant finding count and top topics.' It also differentiates itself from related tools by identifying itself as a convenience wrapper around search_fts, so an agent understands its narrow scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Call this at the start of ANY new task' and 'WORKFLOW POSITION: First tool to call when starting any task.' It does not explicitly state when not to use it or name alternative tools, but the simple yes/no return format implies when a more detailed search is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It does this well by noting that the tool creates one co_scientist_report artifact and compact session summaries, and that mark_complete can move the run phase to complete. This gives the agent a meaningful behavioral picture beyond just 'create a report.'
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 well-organized with clear sections for triggers, workflow position, and parameters. Every section earns its place, and the core purpose is front-loaded. It is detailed but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers prerequisites, side effects, parameters, and workflow context well. It is missing only minor details such as what the returned artifact reference looks like or the behavior when mark_complete is false, but the provided information is sufficient for an agent to invoke the tool 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 description coverage is 0%, so the description must compensate. It provides a PARAMETERS section explaining run_id, created_by, and mark_complete, including the side effect that mark_complete moves the run phase to complete. This adds meaning beyond the raw schema, though run_id could include more detail on where to obtain or validate the run ID.
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 verb and resource: 'Create the final Co-Scientist report artifact for a verified run.' This clearly differentiates it from sibling tools like get_co_scientist_report (retrieval) and export_co_scientist_findings (export), since this tool creates a durable report artifact.
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?
The description explicitly lists automatic triggers and workflow position: after submit_verification has completed for every selected hypothesis, when the user asks for the final report, or before export/memory preservation. It tells the agent exactly when this tool should be called relative to other workflow steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that up to 50 observations are retrieved, that query is optional and falls back to session focus, and that the call can happen mid-session. It does not detail potential side effects such as context-window consumption or whether repeated injections stack, which prevents a 5.
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 well-structured with clear sections for triggers, workflow position, and parameters, with the core purpose front-loaded. There is slight redundancy between the triggers and workflow-position lines, but no meaningless filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, triggers, parameter semantics, and retrieval behavior sufficiently despite having no output schema or annotations. It could more thoroughly differentiate from other retrieval-related siblings such as search_knowledge or retrieve_context, but the essential call path is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's PARAMETERS section adds meaningful semantics for all four parameters: session_id identity, query's optionality and fallback behavior, limit's default, and user_id's isolation purpose. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool auto-injects relevant context from past sessions at any point during work. It explicitly contrasts with session_start, making the tool's mid-session purpose unmistakable and differentiating it from a key sibling.
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?
The description provides explicit automatic trigger conditions: needing a refresher, starting a new subtask, or being asked about prior learnings. It also notes that unlike session_start, inject_context can be called mid-session, giving clear usage guidance relative to an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses auto confidence scoring rules, the read-before-write duplicate check behavior, the confirmation requirement, and that the tool creates persistent data. This goes well beyond what schema alone provides.
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 well-organized with labeled sections and front-loads purpose and when-to-use. It is a bit wordy and contains a typo ('Limitations or cave'), and some statements are slightly redundant, but every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given eight parameters, no annotations, and no output schema, the description covers purpose, triggers, confidence behavior, duplicate-check behavior, confirmation requirements, and all parameters. It is slightly incomplete on the return value and on whether a duplicate suggestion aborts the save or merely warns, which is relevant for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description contains a PARAMETERS section that explains every parameter: what is required, what is optional, how confidence is auto-scored, and the confirm safety gate. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "convenience wrapper for saving findings with automatic confidence scoring." It clearly distinguishes itself from the plain save_finding sibling by emphasizing the auto-scoring behavior, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit trigger conditions: "Call this whenever you discover something important" and "Use when you think 'this is important' or 'this should be remembered'." It does not, however, state when to prefer the sibling save_finding or when not to use this tool, so exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses the central behavioral trait: it does NOT track the read offset and always returns the most recent N messages regardless of prior reads. This makes the lack of side effects clear, though it stops short of describing return ordering or error 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?
Front-loaded with a one-sentence purpose, then organized into trigger list, read_messages differentiation, and parameter bullets. Every section adds value and the structure makes scanning easy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool with no annotations and no output schema, this covers purpose, usage triggers, differentiation, and parameters. Minor gap: it does not describe the return format or message ordering, but that is not critical for a quick read tool.
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 no textual descriptions (0% coverage), so the PARAMETERS section must compensate. It explains session_id, adds the membership constraint for agent_id, and documents n's default and max. This is helpful, though the descriptions are terse.
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?
Clearly states 'Read the last N messages from a session' and frames it as a 'Quick status check without offset tracking'. It explicitly differentiates from read_messages by noting it does not track the read offset, so an agent can distinguish it from siblings.
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?
Provides an explicit 'AUTOMATIC TRIGGERS' list with concrete scenarios: joining a session, quick glance, and checking state before full context load. It also names the key alternative, read_messages, and explains when to use that instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly indicates a read-only operation by saying 'Get' and 'returns raw structured data', and it specifies the returned categories. It could go further with auth or failure behavior, but for a read-state tool this is solid.
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 well-organized with clear sections for purpose, triggers, differentiation, and parameters. Every section earns its place, and the most decision-relevant information is front-loaded in the first sentence.
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 tool with no annotations and no output schema, the description is complete enough: it covers what the tool returns, when to call it, how it differs from the main alternative, and the meaning of both required parameters. An agent has everything needed 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?
The input schema provides no descriptions and schema coverage is 0%, so the description must compensate. It does: session_id is explained as the session identifier, and agent_id is described as 'your agent ID' with a must-belong-to-session constraint. This adds meaningful guidance beyond the bare schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get the current state of a collaboration session') and identifies the returned content: tasks, agents, and session state. It also distinguishes the tool from session_context by highlighting that this returns raw structured data rather than a formatted narrative.
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?
The description includes an explicit 'AUTOMATIC TRIGGERS' section listing concrete situations for calling this tool, and it names the alternative session_context with a clear differentiation. This gives an agent strong guidance on when to select get_session_state over its closest sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds 'gracefully' and 'clean exit' to set expectations, and notes that the reason helps other agents understand, implying the reason is visible to others. However, it leaves implicit what state changes occur, such as whether the session continues or whether other agents are notified.
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 well-structured with a lead sentence, a trigger list, a sibling-differentiation section, and a parameter list. Every section adds needed guidance without redundancies.
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 low-complexity tool with no output schema, it covers the action, when to use it, parameter semantics, and the key sibling distinction. It does not describe return values or failure behavior, but these are not essential for a straightforward leave operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage), so the description fully compensates. It explains session_id as the session to leave, agent_id as the caller's ID, and reason as optional with a clear purpose of helping other agents understand.
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?
States a specific action ('leave a collaboration session') and an explicit design scope ('Clean exit for an agent'). It also differentiates itself from terminate_session, so an agent can tell this apart from the related session-ending sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists concrete automatic triggers: tasks complete, moving to other work, or user request. It also explicitly states that this is for individual agents leaving and that only the orchestrator should call terminate_session, removing ambiguity about which session-ending tool to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It makes the read-only behavior clear by using 'List' and 'Browse', and it discloses that artifact content is not returned here by directing content retrieval to get_artifact. It also states the access constraint that agent_id must belong to the session, but it does not mention ordering, pagination, or result limits.
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 well-structured in short labeled sections and every sentence adds value: purpose, trigger conditions, routing to get_artifact, and parameter semantics. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, triggers, parameters, and the content/get_artifact distinction, which is strong for a filtered read-only list tool with no output schema. It does not describe the exact return shape or mention grep_artifacts as the alternative when searching artifact contents, but that is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% description coverage, but the description's PARAMETERS section fully explains each parameter: session_id as target, agent_id with the session-membership constraint, created_by as an optional creator filter with a natural-language example, and artifact_type with concrete allowed-type examples. This substantially compensates for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'List artifacts in a session.' It also gives concrete artifacts ('work products, analyses, and summaries') and distinguishes itself from get_artifact by explicitly routing content retrieval there.
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 has an explicit 'AUTOMATIC TRIGGERS' section telling an agent exactly when to call it: checking saved work, finding an analysis, or avoiding duplicates before creating a new artifact. It also points to get_artifact when artifact content is needed, giving a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It adds useful behavioral context by stating findings are 'recent' and that the tool is for browsing, not targeted search. However, it does not define what 'recent' means, whether full findings or summaries are returned, or explicitly confirm there are no side effects, which would push it higher.
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 opens with a one-sentence summary, then uses labeled sections for triggers, search alternatives, and parameters. Every section contributes actionable information without filler. The structure is easy to scan and front-loads the most important context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters, the description covers purpose, triggers, alternatives, and parameter semantics. The absence of an output schema means return fields are not described, and 'recent' is left undefined, leaving some uncertainty about ordering and response content. It is sufficient for correct invocation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only type and default values with 0% description coverage. The description fully compensates with a PARAMETERS section: 'limit: Max findings to return (default: 50, max: 200)' adds the maximum bound, and 'offset: Offset for pagination (default: 0)' explains its purpose. Both parameters are clearly and completely described.
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 verb and resource: 'List recent findings in the library.' It further clarifies the tool's scope with 'Use for browsing, not targeted search,' which distinguishes it from search_findings and retrieve_findings. The purpose is immediately clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an 'AUTOMATIC TRIGGERS' section with three explicit conditions: when the user asks to see all findings or browse, when wanting a sense of stored content, and when checking library contents after initialization. It also explicitly routes targeted search to search_findings or retrieve_findings. This provides both strong inclusion and exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does disclose important behavior: offset-tracking, returning only unseen messages, immediate return, and authorization/offset role of agent_id. It could go further by stating whether reading consumes/marks messages as seen and what happens when no messages exist, but the core behavior is clear.
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 front-loaded with the core definition, then organized into scannable sections (AUTOMATIC TRIGGERS, DIFFERENCE, WORKFLOW POSITION, PARAMETERS). Each section adds distinct value and no sentence is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage context, sibling differentiation, and all parameters, which is strong for a read operation. The only notable gap is the absence of any return-shape information, which matters because there is no output schema, though the message model is likely known.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining every parameter's role: session_id, agent_id's authorization/offset purpose, limit's default/max, msg_types with an example, and from_agent filtering. This is far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Read new messages from a session') and a key behavioral differentiator ('Returns only unseen messages (offset-tracked)'). It is clearly distinguishable from sibling tools like poll_messages, tail_messages, and read_message_range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit AUTOMATIC TRIGGERS with concrete situations, names the relevant alternative (poll_messages), and explains when to choose that alternative ('blocking waits in autonomous agent loops'). Workflow position further clarifies when the tool fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the return contents (allowed status, risk level, matched categories, reasons, required approvals) and the blocking implication of allowed=False, making the tool's gatekeeper behavior clear. It does not explicitly state whether the tool is read-only or whether it triggers approvals, but the screening framing and decision output are sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured with a front-loaded purpose, clear trigger bullets, workflow position, parameter explanations, and return-value summary. Every section earns its place, and the length is appropriate for the tool's role as a decision gate.
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?
Given no output schema and no annotations, the description sufficiently explains what the tool returns and how the agent should act on it. It covers parameters, return fields, workflow position, and the critical allowed=False behavior, making the tool actionable without requiring additional 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?
Schema description coverage is 0%, so the description must compensate, and it does. It explains topic as "Proposed research objective" and constraints as "Optional hard limits, domain notes, or requested actions," adding meaning beyond the bare string/array types. This is enough for an agent to populate both parameters correctly, though examples or formatting details are not provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Screen a proposed Co-Scientist run before creating sessions." It clearly differentiates this tool from siblings like create_co_scientist_run by positioning it as the first gate before session creation, and its triggers name Co-Scientist, hypothesis generation, and hypothesis verification.
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?
The description provides explicit automatic triggers with concrete conditions, states the workflow position as "First gate before any Co-Scientist session creation," and gives a clear post-condition: "If allowed=False, do not create a Co-Scientist session." This gives the agent actionable when-to-use and when-to-stop guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the output token range, structured vs. raw nature, and the specific knowledge categories returned (files touched, decisions made, next steps, conventions). It does not explicitly state read-only behavior or error behavior, but the 'Get a synthesized recap' framing makes the non-destructive intent clear.
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 well-structured and front-loaded with the core purpose, then provides trigger conditions, return contents, follow-up routing, and parameter explanations. Every section earns its place; the formatting with bullets makes the usage guidance easy for an agent to parse and act on.
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 two-optional-parameter tool with no output schema, the description is complete: it covers when to call, what it returns, what it does not return, how to follow up for deeper detail, and the meaning of both parameters. Nothing essential is missing for an agent to select and invoke the tool 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 description coverage is 0%, so the description must compensate for parameter meaning. It does: session_id is explained as an optional specific session with a default of recent sessions, and limit is explained as max recent sessions with default 3. This adds practical semantics beyond the raw schema titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get a synthesized recap of recent session knowledge', specifying the resource (recent sessions), the output form (structured, ~150-250 tokens), and explicitly distinguishes itself from raw outputs. It also routes to topic_context for deeper detail, helping differentiate it from that sibling.
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?
Provides explicit 'AUTOMATIC TRIGGERS' with concrete scenarios for when to call this tool first, including starting work, answering 'what have we been working on?', and wanting files/decisions/next steps. It also names topic_context as the follow-up alternative when more detail on a topic is needed, giving clear when-to-use and when-to-use-as-alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the behavioral disclosure burden. It clearly communicates what the tool returns (automatic call rate, paramerer hallucination rate, per-tool breakdown, etc.) and explicitly frames it as a development/evaluation tool. It does not explicitly state 'read-only' or side-effect behavior, but the 'Get...Returns metrics...' framing strongly implies a non-mutating analytic 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 well-organized with clear section headers, automatic triggers, return metrics, and parameter explanations. It is thorough without wasted words; each bullet adds useful information for an agent deciding whether and how to invoke the tool.
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 analytics tool with no output schema and no annotations, the description covers purpose, usage context, parameter meaning, metric output, and exclusions. An agent receives all important information needed to decide whether to call it and how to set the two optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensation for the schema. It provides meaningful semantics for both parameters: 'days: Look back N days (default: 7)' and 'tool_name: Filter by specific tool (optional)'. This adds real value beyond the raw type/default information in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get tool usage analytics and optimization metrics', stating a specific verb and resource. It clearly distinguishes itself as a development/evaluation tool, which sets it apart from the many session, memory, and knowledge tools in the sibling list.
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?
The description contains an explicit 'AUTOMATIC TRIGGERS' section with concrete call scenarios, such as measuring optimization effectiveness and tracking automatic vs explicit call rates. It further states that this is a development/evaluation tool and 'not needed for normal usage', which provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: inclusive start_seq, exclusive end_seq, 500-message maximum, and agent_id session membership. It does not describe error cases or return format, but for a read-only range retrieval tool the coverage is solid.
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 front-loaded with a one-sentence summary, followed by scannable trigger bullets and a compact parameter list. No filler or redundant content; each section earns its place by helping selection or invocation.
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?
Given the tool's moderate complexity and absent output schema, the description covers purpose, triggers, sibling differentiation, and all parameter semantics. It does not explicitly describe the return shape, but 'Read messages' clearly implies the returned content, and nothing needed to select or invoke the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the inline PARAMETERS section fully compensates. Every parameter gets meaningful guidance: start_seq should come from message metadata, end_seq is exclusive with a max range of 500, and agent_id must belong to the session. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and scope: 'Read messages in a specific sequence range'. It clearly distinguishes itself from read_messages by focusing on range-based retrieval rather than 'new' messages, so an agent can differentiate it from related message tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'AUTOMATIC TRIGGERS' section explicitly lists when to call the tool (e.g., 'A message references an earlier seq number', 'review a specific exchange between agents'). It also names the alternative read_messages and explains the difference, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and does so thoroughly. It discloses the duplicate-check behavior with a similarity threshold, the confirmation requirement, session awareness warnings, and that this creates persistent data. These are meaningful behavioral traits beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but exceptionally well organized into labeled sections: automatic triggers, exclusions, workflow, read-before-write, session awareness, confirmation tier, and parameters. Each section adds necessary information without filler, and the most important usage guidance 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 complex 11-parameter write tool with no annotations and no output schema, the description covers triggers, exclusions, parameter semantics, duplicate handling, confirmation, and session dependencies. It falls slightly short by omitting three parameters and not specifying the success response shape, but overall it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains most parameters well with usage guidance (confidence scale, confirm safety gate, evidence/reasoning/caveats purpose). However, it omits full_text, finding_id, and proposed_by, leaving their semantics undocumented, which keeps this from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Save critical research findings, discoveries, and insights to persistent library.' It clearly differentiates from siblings by listing automatic triggers and explicit DO NOT CALL cases, so an agent knows this is for persistent insight storage rather than temporary notes or tool outputs.
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?
The description provides explicit when-to-call triggers, a DO NOT CALL list, workflow positioning, and a tip to use search_findings first for deduplication. This gives strong, unambiguous guidance on when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by revealing the lightweight, fast, metadata-only nature of the search and approximate token cost per result. It could go further by specifying relevance ordering or match semantics, but the disclosed behavior is sufficient for a search 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 well-organized with clear headers, bulleted triggers, and a separate PARAMETERS section. The most important information is front-loaded, and every section contributes actionable guidance without redundancy or filler.
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?
Given the tool's moderate complexity, no annotations, and no output schema, the description is remarkably complete. It covers call triggers, return type, cost, filtering strategy, parameter details, and the recommended follow-up tools. An agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters itself. It does: query is described as 'Search query,' limit gets a default and meaning, and filters gets a concrete JSON example including useful keys like tool_name and session_id. The SEARCH STRATEGY section adds practical keyword guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Lightweight search of memory index' and 'Fast metadata search.' It clearly distinguishes itself from memory_timeline and get_observations by positioning itself as the first-pass filter that returns compact metadata, avoiding any tautology or ambiguity.
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?
The 'AUTOMATIC TRIGGERS' section explicitly lists when to call this tool: to identify relevant memories, before fetching full observations, and when searching by tool name/type/session. It also provides a direct workflow comparison: use this FIRST, then use memory_timeline or get_observations for details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It clearly discloses that the tool performs three combined operations (session creation, context injection, initial finding search) and describes the return payload. It does not cover potential side effects or state changes beyond session creation, but it is quite transparent for a composite startup 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 uses clear section headers (AUTOMATIC TRIGGERS, WORKFLOW, PARAMETERS) that front-load the most important usage information. Every section adds value, and the bullet lists keep it scannable rather than dense prose.
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?
Despite having no output schema or annotations, the description tells the agent when to call it, what it does internally, what it returns, and what to do next. The workflow instructions complete the loop by pointing to save_finding and session_end, making it self-contained for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only semantic source for parameters. It describes all four parameters with meaningful context: session_id (unique session identifier), topic (used to find relevant context), user_id (optional identifier), and limit (max observations to inject, default 50). This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Begin a complete research session with automatic context loading.' It further clarifies the composite nature with 'This replaces calling session_start + search_findings separately,' which distinguishes it from sibling tools like session_start and search_findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit 'AUTOMATIC TRIGGERS' section listing three precise conditions for use, and it explicitly states what it replaces. The WORKFLOW section then guides the agent to call save_finding afterward and session_end when done, leaving no ambiguity about sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It clearly states the operation is DESTRUCTIVE, PERMANENT, cannot be undone, requires confirm=True, and that the finding is permanently removed. It also instructs the agent to warn the user beforehand, going well beyond the bare 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 well-structured and front-loaded with the critical warning. While there is some repetition of the destructive/permanent message across multiple sections, the redundancy is arguably justified for a safety-critical destructive operation and does not obscure meaning.
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 is complete for this tool's complexity: it covers the action, required parameter, confirmation safety gate, permanent consequences, user-warning duty, and excludes misuse cases. No output schema exists, but a delete operation with this guidance does not require additional return-value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description documents both parameters: finding_id as the required ID to delete, and confirm as a mandatory safety gate that must be True. This adds meaningful semantics beyond the schema's bare type/default declarations, especially clarifying the confirm parameter's behavioral role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Delete a finding by ID.' It clearly contrasts with sibling operations like get_finding, save_finding, and list_findings, and even identifies update as the correct action for duplicates. An agent can immediately understand what this tool does and how it differs from nearby tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit call conditions under 'AUTOMATIC TRIGGERS' and explicit exclusions under 'DO NOT CALL for,' including naming 'update instead' for duplicate cleanup and forbidding calls without explicit user confirmation. This is exemplary when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it succeeds: it discloses that the tool creates persistent resources, that initialization is permanent, and that calling it multiple times is safe because it will skip if already initialized. It does not claim read-only behavior or hide its mutating nature.
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 appropriately structured with a one-sentence summary, explicit trigger lists, and a do-not-call list. Every sentence adds operational value and the most important guidance ('Call this ONCE') 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 zero-parameter init tool with no output schema, the description covers everything an agent needs: when to invoke it, what it does, what resources are created, and its idempotent behavior. There is no missing context that would prevent correct 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 tool has zero parameters and the input schema is empty, so there is nothing to document. The description correctly avoids inventing parameter details, and the baseline for zero-parameter tools is an appropriate 4.
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 identifies the tool as an initialization step: 'Initialize the OpenLMlib knowledge base' and explicitly states it creates 'the SQLite database, vector index, and required directories.' This distinguishes it from the many sibling tools that operate on an existing knowledge base, and the 'before using any other tools' directive makes its role unmistakable.
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?
The description provides explicit automatic triggers (first use, database errors, user request) and explicit non-triggers ('Normal tool usage', 'Each session start'). It clearly tells the agent when this tool should be called and when it must not be called, which is exactly the usage guidance an agent needs for an initialization-only tool.
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:

[![OpenLMlib MCP server](https://glama.ai/mcp/servers/Vedant9500/OpenLMlib/badges/card.svg)](https://glama.ai/mcp/servers/Vedant9500/OpenLMlib)

Score Badge

Copy to your README.md:

[![OpenLMlib MCP server](https://glama.ai/mcp/servers/Vedant9500/OpenLMlib/badges/score.svg)](https://glama.ai/mcp/servers/Vedant9500/OpenLMlib)

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/Vedant9500/OpenLMlib'

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