headlo-mcp
OfficialServer Quality Checklist
Latest release: v1.0.2
- Disambiguation4/5
Most tools have a clear and distinct resource+action purpose (e.g., create_record vs update_record, list_pages vs create_page). The main confusion risk is between list_page_modules and list_modules_editor, which differ only by auth context, and possibly get_module vs list_page_modules, though the singular/plural distinction helps.
Naming Consistency3/5The dominant pattern is verb_noun (get_context, create_site, update_record), but there are notable deviations: 'cap_capture_expert' and 'cap_edit_expert' use a prefix and less predictable structure, and 'list_modules_editor' is inconsistent with 'list_page_modules'. Overall still readable but not uniform.
Tool Count4/525 tools is at the high end but well-justified given the server covers multiple domains: onboarding, sites, pages, collections, records, modules, and expert protocols. Each tool serves a distinct purpose, though the count feels slightly heavy for a single server.
Completeness2/5There are significant lifecycle gaps: no delete or update for sites, no delete for pages, no delete for collections, and no get_collection or update_site. Records and modules have full CRUD, but the broader content model lacks essential operations that agents would likely need.
Average 3.2/5 across 25 of 25 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Elastic License 2.0.
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.jsonto 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
- Behavior1/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 only says 'Delete a record', omitting critical facts such as irreversibility, permission requirements, or the confirmation mechanism. This is a destructive operation with zero transparency about its effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but not in a good way—it is under-specified. It consists of two words that restate the tool name, providing no substantive content. This is not conciseness but a failure to convey necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and is destructive. The description only covers the basic action with no context about the deletion scope, confirmation requirement, effects, or any other important behavior. It is woefully incomplete for an agent to safely invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters. Schema coverage is 50% (confirm and workspace_id have descriptions), but the description adds no extra meaning. The record_id and collection_id parameters remain undocumented in both the description and their own schema entries, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a record' is a direct restatement of the tool name 'delete_record', providing no additional information. It fails to distinguish from sibling tools like 'delete_module' or specify any scope or target context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, intended scenarios, or why one might prefer this over other deletion tools, leaving the agent without orientation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure, but it only says 'Create a new collection.' It does not reveal any behavioral traits like duplicate handling, permission requirements, or side effects, making it effectively transparent only in the most literal sense.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is not verbose and earns its place as a clear action statement. However, it is arguably too minimal for the tool's complexity, though this is more a completeness issue than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters including a complex nested schema, no output schema, and no annotations. The description provides minimal context—no purpose details, no setup requirements, no return value information—making it completely inadequate for the agent to understand how to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only collection_id documented. The description text adds nothing about label, workspace_id, or the schema nested object. Even the schema property definitions are sparse, and the description fails to explain how to construct the schema fields array, leaving most parameters semantically under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'collection', distinguishing it from sibling tools like update_collection and list_collections. However, it lacks any scope elaboration—it does not explain what a collection is or what makes it distinct from other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like update_collection, nor does it mention any prerequisites such as needing an existing workspace or what a collection represents in the system.
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. 'Add' implies a mutating operation, but no side effects, prerequisites, or behavior regarding existing modules in the slot are disclosed. This is insufficient for a creation tool with complex parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is terse and front-loaded, which is efficient, but it omits essential context needed for a tool with six parameters. It is under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (6 parameters, nested object, no output schema, no annotations), the description is substantially incomplete. It lacks information about return values, prerequisites, and parameter relationships, making it only minimally useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the six parameters. It does not explain the roles of template_id, collection_id, template_options, or collection_record_id, leaving the agent to infer semantics solely from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a module to a page slot' clearly states the action and resource, distinguishing it from sibling tools like list_page_modules, get_module, or delete_module. However, it does not explicitly contrast with these siblings, so it is clear but not fully differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as update_module or create_page. There are no contextual cues, exclusions, or references to sibling tools, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic create action, but does not mention side effects, permission requirements, duplicate handling, or return behavior. This is insufficient for an agent to understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words, making it easy to parse. However, it is underspecified and lacks key context, so it is not optimally structured for an agent needing to decide on invocation. It is brief but not comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 4 parameters, no annotations, and no output schema, the description is too minimal. It does not explain return values, error handling, relationships to sibling tools, or any operational constraints. This leaves significant gaps in the agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 25% description coverage (only page_id is described). The tool description adds no parameter information, failing to clarify the meaning or requirements of title, site_id, or layout_id. Since the schema coverage is low, the description should compensate, but it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (create) and resource (page), which distinguishes it from sibling creation tools like create_site or create_record. However, it lacks scope details such as 'in a specific site' or 'with a layout', so it doesn't fully differentiate the tool's purpose from other page-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as update_page or create_site. There is no mention of prerequisites, target use cases, or exclusions. An agent must rely solely on the tool name and schema to infer appropriate usage.
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 available, the description carries the full burden of behavioral disclosure. It merely states 'Create a new record' without explaining mutation semantics, default behaviors (e.g., status default), or what the operation returns. It essentially restates the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (8 words), which is easy to parse and front-loaded. However, it is under-specified and omits critical context, so conciseness comes at the expense of usefulness. It is not a tautology, but it barely exceeds a minimal phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (4 params, nested objects) with no output schema and no annotations. The description explains neither return values nor operational details, leaving the agent with insufficient information to invoke correctly. It fails to compensate for the missing structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, and the description adds no parameter-level information. The schema provides some meaning via descriptions for data and workspace_id, but collection_id is undocumented, and status has only an enum. The description does nothing to clarify parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'record in a collection', which distinguishes it from siblings like update_record or create_collection. However, it lacks detail about what creating a record entails (e.g., field values) and could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, exclusions, or relationships with sibling tools like create_collection or create_page.
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 says 'save' which implies a write, but does not reveal whether it overwrites existing branding, merges, requires specific agency state, or how it handles the optional parameters. No return value or error behavior is described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is concise and to the point, though the lack of detail limits its value. The structure is clean and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 optional string parameters and no output schema, the description is still incomplete. It lacks behavioral context (overwrite vs. merge), safety profile, and success/failure semantics. Given no annotations, the description should provide more substance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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. It does not mention logo_url or primary_color at all, despite naming them in the schema. The description adds no meaning to the parameter names beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save') and the resource ('branding details for the active agency'). It is specific enough to distinguish from siblings, though 'active agency' is a bit ambiguous and not elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, side effects, or any context like initial setup vs. updating existing branding. Siblings like setup_agency might overlap, but no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it updates a page, but provides no information on side effects, permissions, idempotency, or how partial updates are handled. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant wording. It is front-loaded and easy to parse, though it could arguably include more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no annotations, and no output schema, the description is incomplete. It does not explain the status parameter, the page_id identifier, or any behavioral aspects. It only scratches the surface of what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must explain parameter semantics. It mentions 'title' and 'layout', which map to the title and layout_id properties, but leaves page_id and status unexplained. This partial coverage does not adequately compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as updating a page and specifies the updatable properties (title or layout). It distinguishes from sibling update_* tools by naming 'page' as the resource. However, it omits the 'status' field, making the scope slightly incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of related tools like create_page or update_module, nor any indication of prerequisites or context where this tool should be selected.
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 adds that drafts are included, but does not mention that the operation is read-only, default pagination behavior, or how results are ordered, which are critical for an agent to understand the tool's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence with no redundant words, front-loaded with the verb 'List'. It efficiently communicates the core purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters (1 required) and no output schema, the description is too sparse. It fails to explain pagination, filtering, or how to specify the collection, leaving the agent to infer critical usage details from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the tool description does not explain any parameters such as collection_id, limit, offset, or status. The only hint, 'includes drafts', is not tied to the status parameter and does not compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists records in a collection and highlights that drafts are included. This distinguishes it from get_record, which fetches a single record, and other list tools for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_record or similar list tools. It does not mention any prerequisites, exclusions, or specific use cases beyond the basic listing action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/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 of behavioral disclosure. It only states a create action and gives no information about side effects, permissions, failure modes, or whether the operation is reversible. This is insufficient for a write 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the verb and object, making it easy to scan and understand immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (1 parameter, no output schema), the description omits crucial context such as return value, prerequisites for having an 'active agency', and behavior on failure. With no annotations to fill gaps, the description is too spare for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'name' parameter thoroughly (type, required, example). The description adds no additional parameter semantics, so the baseline of 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('new site') with context ('under the active agency'), making it distinct from sibling tools like create_collection or create_page. No ambiguity about what this 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an active agency), exclusions, or recommended workflows. The phrase 'under the active agency' hints at a condition but does not offer explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Behavioral transparency is low. The description only states the action 'Remove', but does not disclose that deletion is permanent, requires confirmation (despite the confirm parameter), or any cascading effects. With no annotations available, the description fails to carry the burden of explaining the destructive nature and safety requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is an efficient single sentence that immediately communicates the action and object. It is appropriately sized and front-loaded with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with a confirmation parameter, the description is incomplete. It lacks critical context about irreversibility, the confirmation requirement, and any side effects. The absence of output schema and annotations makes the description's brevity a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level information. While the schema documents the 'confirm' parameter with a description, 'module_id' has no description and the description text does not explain either parameter beyond what the schema provides. With 50% schema coverage, the description should have compensated but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' with a clear resource 'module' and location 'from a page', clearly distinguishing it from sibling tools like create_module, update_module, and get_module. It succinctly conveys the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when this tool should be used over alternatives, nor does it state any prerequisites or scenarios. For example, there is no mention that users should confirm before deletion or that this is for removing a module from a page versus editing it.
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. It discloses the authentication model ('public, anon key auth') but does not mention error behavior, pagination, rate limits, or permissions beyond auth. The read-only nature is implied by 'get' but not explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys purpose and auth context without waste. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a single parameter, the description is under-specified. It lacks details about return structure, error cases, and relationship to other module tools. The auth note is helpful but not sufficient for full agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 not explain the format or provenance of module_id, only implying via 'single module' that this parameter identifies which module to fetch. The param name is self-explanatory but the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('a single module') with scope ('with its records'), clearly distinguishing it from sibling tools like list_page_modules or get_record. The 'single' qualifier makes the one-record nature explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_modules_editor or get_context. The parenthetical 'public, anon key auth' hints at public-facing usage but does not explicitly state exclusions or preferred contexts.
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 must carry the burden of behavioral disclosure. It only mentions 'editor auth' as a context, but does not explain what that entails, nor does it describe return format, ordering, pagination, or error conditions. For a list operation, more detail could be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and scope. Every word is purposeful, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema), the description is adequate for basic purpose but lacks usage guidance and deeper behavioral context. It does convey the essential function and a hint about auth, but more detail on return behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (page_id) with no description, and the description only indirectly references it via 'on a page'. This adds some meaning but does not explicitly explain that page_id is the identifier of the page whose modules are listed, nor does it provide format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all modules') and the scope ('on a page'), with a parenthetical qualifier about editor auth. It distinguishes from siblings like get_module (single module) but not clearly from list_page_modules, which may be a close sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like list_page_modules. The editor auth hint is implicit but no when-not conditions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states that the tool updates, but doesn't mention validation, side effects, reversibility, permissions, or whether partial updates are allowed. The word 'update' is implicit in the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no filler or redundancy. Conciseness is excellent, though it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested schema object, no output schema, no annotations), the one-line description is inadequate. It doesn't explain how to structure the schema update, what validation rules apply, or what response to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 mentions 'label' and 'schema' but doesn't explain the required collection_id parameter or the structure of the nested schema object. This adds minimal meaning beyond the schema's field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('collection'), and clarifies the scope ('label or schema'), which distinguishes it from sibling tools like update_record, update_page, and create_collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives such as update_record or create_collection. There are no prerequisites, exclusions, or context beyond the verb and resource.
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?
Since no annotations are provided, the description carries full responsibility for behavioral disclosure. It only mentions the update action and the updateable aspects, but does not disclose side effects, permissions, reversibility, or what happens to existing settings. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, and every word adds value. It is appropriately sized with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 4-parameter mutation tool with no annotations and no output schema. The description is too sparse to cover important context such as whether the update is partial or full, required parameters beyond module_id, any dependencies between parameters, or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps 'record', 'options', and 'template' to the parameters collection_record_id, template_options, and template_id, adding semantic meaning beyond the bare schema. However, it does not explain the format or constraints of each parameter, and module_id is only implied by the phrase 'a module'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'a module', and enumerates the three specific aspects (record, options, template) that can be changed. This differentiates it from sibling tools like update_collection or update_record in the same group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as create_module or update_collection, nor any prerequisites or exclusions. The description simply states what it does, leaving the agent to infer proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It only states 'List all pages' without mentioning return format, pagination behavior, or any side effects. The read-only nature is implicit but not stated, and no other behavioral details are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It communicates the core action and target resource efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns, but it does not. It also lacks information about pagination, error handling, or required site existence. While the tool is simple, the description is too minimal to be fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (site_id) with 0% description coverage. The description only says 'for a site', hinting at site_id's role but not explaining its format, constraints, or meaning. This does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all pages for a site' uses a specific verb and resource, clearly distinguishing it from sibling tools like list_page_modules. The scope ('for a site') is explicit and matches the required site_id parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this tool when you need a list of pages for a given site. However, there is no explicit guidance on when to use alternatives or what distinguishes it from seemingly related tools like list_page_modules or get_context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full responsibility for behavioral disclosure. It does reveal important constraints (web search requirement, 4–6 facts per answer), but it omits side effects (e.g., whether existing protocols are overwritten), permission requirements, or return behavior. This is a moderate disclosure level for a create 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the purpose clearly front-loaded in the first sentence. It wastes no words and conveys the essential process requirement in the second sentence, earning a high score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested schema, but the description is brief (only two sentences). While the schema covers parameter meanings, the description omits contextual information such as when to use the tool, what happens upon creation, or how the protocol will be used afterward. It is adequate but leaves noticeable gaps for a create tool with this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptive parameter text, so the baseline is 3. The description adds meaningful value beyond the schema by specifying that each probe answer must contain 4–6 specific facts sourced from research, which directly informs the 'answer' field and enforces an expected quality level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a CAP') and the specific resource ('Context Accumulation Protocol for a question on the Headlo Ask network'), which distinguishes it from generic create tools. However, it does not explicitly contrast with similarly named siblings like cap_capture_expert or cap_edit_expert, leaving some ambiguity in tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides procedural guidance ('always do a web search before writing any knowledge probes') but does not explain when to use this tool versus alternatives like cap_capture_expert or cap_edit_expert. There is no explicit mention of use cases, exclusions, or prerequisites, so the agent receives little help in deciding to invoke this tool.
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 must carry the full burden of behavioral disclosure. It only indicates a read operation ('Get') but does not clarify what 'onboarding step' or 'completion status' means, how it is determined, or whether any side effects exist. Additional context about return structure or context dependency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose without waste. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate for a simple read tool with no parameters or output schema. However, it lacks any elaboration on what the returned data looks like, what 'onboarding step' refers to, or whether there are any contextual dependencies, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly implies that no inputs are needed, and there is no parameter information to add. The description adds no misleading semantics about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and a distinct resource ('onboarding progress'). It differentiates from siblings like get_context or get_record by focusing specifically on onboarding step and completion status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or recommended contexts, leaving the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'create,' which conveys mutation but does not explain side effects, permissions, idempotency, or response behavior. This is insufficient for a write operation without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the action and object. Every word contributes meaning, with no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description plus schema adequately cover the core purpose and input. The onboarding context adds situational completeness. It does not explain return values or side effects, but the low complexity mitigates the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'name' with the description 'Agency or business name.' The tool description adds no additional semantic nuance beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new agency/workspace during onboarding,' which uses a specific verb and resource. It clearly distinguishes from sibling tools like create_site or create_collection by focusing on 'agency/workspace' and specifying the onboarding context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'during onboarding' implies when this tool is appropriate, but there is no explicit mention of when not to use it or alternatives. Unlike the high-calibration example, it does not name a sibling tool for alternative cases, so guidance is only 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 provided, the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation and 'all field values' suggests the return content, but it omits any details about auth requirements, error handling, workspace_id resolution, or access restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the tool's core function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with few parameters and no output schema. The description is mostly sufficient, clarifying purpose and return content. A minor gap is not mentioning that collection_id is required, though the schema does indicate this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only workspace_id has a description). The description adds some meaning for record_id ('by ID') but doesn't elaborate on collection_id, which is a required parameter. This leaves a significant portion of the parameters contextually unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and clearly identifies the resource: 'a single record by ID' with scope 'all field values'. This distinguishes it from sibling tools like list_records and other record operations, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description and name: use when you need a single record by ID. However, it doesn't explicitly state when to use this tool over list_records or other alternatives, nor does it provide any exclusions or prerequisites.
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 disclose behavioral traits. 'List' implies a read-only operation, but the description does not state return format, pagination, ordering, or side effects. The scoping to 'active workspace' adds some context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the core function without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description covers the essential purpose but omits details about the return value structure and any edge cases (e.g., empty workspace, permissions). It is adequate but minimal, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, workspace_id, is fully described in the schema with 100% coverage. The description adds no extra parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all collections for the active workspace' uses a specific verb (List) with a clear resource (collections) and scope (active workspace). It clearly distinguishes from sibling tools like create_collection, update_collection, list_records, and list_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context ('active workspace') but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or complementary tools are mentioned, leaving the decision to the agent's inference from the tool name.
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 for behavioral disclosure. It does reveal a key behavior—partial updates that leave unspecified fields unchanged—but it does not mention failure modes, return values, or any side effects. This is sufficient for a basic CRUD operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It earns its place by conveying the essential partial-update semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description leaves notable gaps: no mention of error behavior, return values, or that status can be updated directly. For a mutation tool with five parameters, this level of detail is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 40% of parameters have schema descriptions, and the tool description adds no parameter-level guidance. The phrase 'provided fields' alludes to the data object but does not clarify other parameters like status, collection_id, or record_id. The description fails to compensate for the schema's low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('update') and resource ('record'), clearly distinguishing from sibling tools like create_record, delete_record, and get_record. The phrase 'partial update, only provided fields are changed' adds precision about the operation's 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this tool is for modifying existing records with granular control, implying use when only specific fields need changing rather than a full replacement. However, it does not explicitly name alternatives or state when not to use it, so it stops short of 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?
No annotations are present, so the description carries the full burden. It discloses the public anon key auth requirement and indicates that records are included in the result ('with their records'), which adds behavioral context beyond the tool name. However, it does not describe return shape or pagination 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: verb, resource, and scope appear immediately, with the auth context appended in a parenthetical. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers core purpose and auth context. However, it lacks explicit guidance on how this differs from list_modules_editor, leaves page_id format ambiguous, and does not clarify how records are represented in the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, page_id, has 0% schema description coverage. The description merely reuses the word 'page' ('on a page') and does not explain the expected format, type, or how the value maps to a page resource beyond the property name, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('modules on a page') and adds a distinctive detail ('with their records'), making it easy to distinguish from get_module (single item) and list_modules_editor (editor context).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'public, anon key auth' provides clear context for when this tool should be used (public/anonymous access), but it does not explicitly contrast with the sibling list_modules_editor 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.
- 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 correctly implies a read-only operation ('Get') scoped to the active agency, but does not disclose response format, whether it includes nested details, or any potential edge cases (e.g., no sites/workspaces). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action, and contains no redundant or filler information. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no output schema, the description sufficiently conveys the tool's role as an orientation entry point. It mentions the key resources (sites and workspaces) and the operational context (active agency). Slightly more detail about the return structure could improve it, but the simplicity and usage cue make it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by definition. Per the rubric, the baseline for 0 params is 4. The description adds no parameter semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all sites and workspaces for the active agency, using a specific verb ('Get') and resource. This distinguishes it from sibling tools that focus on individual modules, records, or pages, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'call this first to orient yourself' explicitly tells the agent when to use the tool (before others) and why (orientation). It does not list alternative tools or exclusions, but the temporal guidance provides strong context for 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, the description carries the full burden. It discloses that this is a stateful session requiring session_state to be passed back, and it describes the final return shape. It does not mention error handling or side effects, but for a non-destructive capture tool, the transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the primary purpose, and includes the return shape without redundancy. Every sentence adds value, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's interactive nature and lack of output schema, the description explains how to start, continue, and finish the session, and lists the return fields. It lacks explicit error scenarios or preconditions, but it covers the core workflow sufficiently for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds macro-level semantics by tying the parameters into a workflow: empty message starts, message answers, session_state loops. This goes beyond the per-parameter descriptions in the schema, which are already detailed; the description reinforces the session protocol.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run an existing CAP (Context Accumulation Protocol) as a live intake session.' It specifies the exact verb and resource, and the interactive flow distinguishes it from sibling tools like create_expert_protocol and cap_edit_expert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage guidance: pass cap_id and an empty message to start, answer each question in subsequent calls, and pass back session_state. It does not explicitly name alternatives but the usage pattern is unambiguous and context-rich.
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 discloses a non-trivial conversational workflow: initial load requires cap_id and empty message, session_state must be passed back unchanged, and the return shape is described. It implies mutation via add/remove/edit but does not mention reversibility, permissions, or failure modes. This is solid but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the tool's purpose and operations, the second describes the initialization pattern and return type. No filler, front-loaded, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (conversational, stateful, no output schema), the description covers the essential workflow: how to start, how to continue, and what the response contains. It provides enough guidance for an agent to invoke the tool correctly and handle the session. Minor omissions like error handling are acceptable at this level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all three parameters (100% coverage), so baseline is 3. The description adds interaction semantics beyond the schema: that the first message must be empty to load the CAP, and that session_state is opaque and must be passed back unchanged. This clarifies the multi-turn protocol.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool edits an existing CAP and lists specific operations: add questions with AI-generated knowledge probes, remove questions, and edit multiple-choice options. The verb 'edit' and resource 'existing CAP' distinguish it from sibling cap_capture_expert (which presumably captures/creates) and generic CRUD tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: conversational editing of an existing CAP, with explicit instruction to pass an empty message on first call and session_state on subsequent calls. It does not explicitly name alternatives or state exclusion criteria, but the intended scenario is evident from the description.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/headlohq/headlo-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server