mcp-server-scf

Server Quality Checklist

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

Latest release: v1.7.0
Disambiguation3/5
While each tool has a distinct purpose, the high number (88) and many similar-sounding tools for evidence, assessments, and vendors could cause an agent to select the wrong one. For example, there are multiple tools for evidence assessment (scf_get_evidence_assessment, scf_get_evidence_assessment_summary, scf_get_window_assessment, etc.) that a model might confuse.
Naming Consistency4/5
The majority of tools follow a consistent 'scf_<verb>_<noun>' snake_case pattern. Verbs like get, list, create, update, delete are used predictably. Minor deviations like 'scf_scope_framework' and 'scf_batch_update_controls' are present but do not significantly harm overall consistency.
Tool Count2/5
With 88 tools, this server feels overloaded. While it covers a broad compliance domain, the sheer number suggests it could be split into multiple smaller servers (e.g., evidence, risks, vendors). This many tools in one server increases cognitive load and selection complexity.
Completeness4/5
The tool set covers a wide range of SCF operations: organization management, control catalog, scoping, evidence tracking and AI assessment, risk management, vendor management, systems, capabilities, and webhooks. Some CRUD operations are missing (e.g., no delete for scoped controls), but overall it is comprehensive for the domain.
Average 3.9/5 across 88 of 88 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on July 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?
No annotations are provided, so the description must disclose behavioral traits. It only states what is returned, but fails to mention that the operation is read-only, any permission requirements, or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, tightly focused on the tool's output. It is efficient and front-loaded, though it could sacrifice some completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context on return structure, error conditions, or behavior. It only lists content types, leaving significant gaps for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description that explains how to obtain the value. The tool description adds no additional parameter meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'vendor', and enumerates the data included (certifications, assessments, risk score, research results). This clearly differentiates it from siblings like scf_list_vendors (list) or scf_get_vendor_research (only research).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like scf_list_vendors or scf_get_vendor_research. It implies it's for a single vendor detail, but no guidance on prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states the tool lists capabilities without disclosing whether it is read-only, whether pagination exists, or any required permissions. This is insufficient for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that efficiently convey the purpose. No unnecessary words or information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, likely a list), the description is adequate but incomplete. It does not indicate the structure of the return value or any pagination behavior, which is needed since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the required org_id parameter, which is well-documented with format and source instructions. However, the tool description does not reference the parameter or add meaning beyond the schema, meeting the baseline but not enhancing 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 states the tool lists capabilities for an organization, using a specific verb and resource. It provides additional context that capabilities map to systems and evidence, but does not explicitly distinguish it from sibling tools like scf_list_capability_themes, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives such as scf_get_capability_theme or scf_list_capability_themes. No prerequisites or exclusions are mentioned, offering no decision criteria.
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 discloses that the operation is a write (creation) and requires "editor+" role. It also notes potential linking to capabilities/evidence. However, it does not mention side effects (e.g., whether name must be unique), error conditions, or the return value.
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?
Two sentences deliver the essential information: action, resource, role, and a key relationship. No superfluous words. Front-loaded with the main purpose.
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 is adequate for a simple create operation with good schema coverage, but it lacks details on return values, failure modes, or uniqueness constraints, which would be useful given the 9 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra parameter meanings beyond what the schema already provides; it only adds a general note about linking to capabilities/evidence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ("Create") and resource ("system in the organization's infrastructure inventory"). It also mentions the required role ("editor+") and that systems can be linked to capabilities/evidence. However, it does not explicitly differentiate from the sibling tool scf_update_system, though the verb implies creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the required role ("editor+") but provides no guidance on when to use this tool versus alternatives like scf_update_system or scf_list_systems. There is no mention of prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions output type (freshness status, roll-up summary) but omits side effects, permissions, error handling, or rate limits. The description is insufficient for a comprehensive behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the tool's purpose and output. No redundant or extraneous information.
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 one parameter and no output schema. The description gives a high-level overview of output but does not specify exact fields or structure. For a simple tool, this may suffice, but more detail on the roll-up summary format would improve completeness.
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 covers 100% of parameters with a clear description for org_id, including format and source. The tool description adds no additional parameter context, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves evidence collection health with per-item freshness status (green/amber/red) and a roll-up summary. It distinguishes from siblings like scf_get_evidence_maturity by focusing on freshness against collection frequency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as scf_get_evidence_validation or scf_get_evidence_maturity. The description only states what it does without contextual usage advice.
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 provided, so the description carries full burden. It mentions listing roles, implying read-only, but does not explicitly state it is a safe, non-destructive operation. No mention of auth needs, pagination, or 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?
Single sentence, no wasted words. Front-loaded with action and key details (members + roles).
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?
Adequate for a simple list tool with one parameter, but missing output description (e.g., format of returned members list, any pagination) and no behavioral context. Could be more complete given no annotations or output schema.
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 100% with a description for org_id that references scf_list_organizations. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list members), the scope (one organization), and the output includes roles (admin, editor, viewer). It distinguishes itself from siblings like scf_list_organizations, which lists organizations, not members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. While there are no other member-listing siblings, the context signals suggest many list tools, but the description does not explicitly state when this is appropriate (e.g., after getting an org_id from scf_list_organizations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions listing and optional filtering, but omits details like pagination, sorting, return format, or any side effects. For a read operation, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action. It is concise, but could include a brief note about the return value without becoming verbose.
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?
The tool has no output schema and 100% schema coverage, but the description lacks information about the response structure or any constraints. It does not differentiate from scf_list_system_catalog or indicate whether results are paginated.
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 100% with detailed parameter descriptions (org_id and vendor_id). The description adds context 'linked vendor' but does not significantly extend understanding beyond 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 clearly states it lists infrastructure systems (tools and platforms implementing security capabilities) with optional vendor filtering. It uses a specific verb 'list' and distinguishes from sibling tools like scf_list_vendors and scf_create_system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing systems but provides no explicit guidance on when or when not to use this tool versus alternatives like scf_list_system_catalog. No context is given for prerequisites or 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?
With no annotations, the description conveys that this is a write operation and lists the checks performed. However, it does not disclose potential side effects, permission requirements beyond role, or whether the operation is synchronous or asynchronous.
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 brief and front-loaded: two sentences clearly state the action, required role, checks, and return value, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters and no output schema, the description explains what it checks but omits details like expected output format, error conditions, asynchronicity, or prerequisites beyond role.
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 100%, so the schema already documents parameter meanings. The description adds no new parameter information beyond listing general checks, achieving baseline adequacy.
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 re-runs validation on an evidence file, listing specific checks (catalog existence, content type, etc.). However, it does not explicitly distinguish this from similar sibling tools like scf_get_evidence_validation or scf_trigger_evidence_assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description mentions 'editor+ role' for write access but lacks context for appropriate scenarios.
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 full burden. It discloses key effects: auto-generates code and creates risk assessment record. However, it lacks details on side effects, permissions beyond role, or rate limits.
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?
Description is concise (one sentence plus parenthetical) and clearly states the action, role, and automatic behaviors. However, it could benefit from slightly more structure, such as listing key parameters or effects.
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 creation tool with no output schema, the description covers the main action and auto-generation details. Missing hint about return value (likely created risk ID) but overall adequate.
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?
Input schema covers all 5 parameters with descriptions (100% coverage). The tool description adds minimal parameter context beyond the schema, such as the role requirement, but does not elaborate on specific parameter usage.
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?
Description clearly states the tool creates a custom org-defined risk, specifies it's a write operation requiring editor+ role, and mentions auto-generation of code and assessment record. It distinguishes from other risk tools by the term 'custom org-defined', but does not explicitly contrast with sibling scf_create_risk.
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?
Description indicates when to use (to create a custom org-defined risk) and the required role (editor+), but does not provide when not to use or mention alternative tools like scf_create_risk for standard risks.
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?
Without annotations, the description carries the full burden. It discloses that the operation is a write and that it starts tracking, but it does not discuss side effects, authentication details beyond role, idempotency, error states, or what happens on duplicate evidence_id.
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 two sentences, free of fluff, and front-loads the core action. Every word adds value.
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 10 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what the tool returns (e.g., the created record ID), how tracking works, or the impact of optional parameters. The tool's complexity demands more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 10 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds no parameter-specific information; it only references evidence_id implicitly. It does not clarify the meaning or usage of optional parameters like owner or frequency.
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 verb 'Create', the resource 'evidence tracking record', and the source 'from a catalog evidence ID'. It also specifies the role requirement 'editor+'. This distinguishes it from siblings like scf_update_evidence by implying creation vs. update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (to create a new tracking record) and implies a prerequisite (need a catalog evidence ID from scf_list_evidence_catalog). However, it does not explicitly state when not to use or mention alternatives such as scf_update_evidence for modifying existing records.
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?
Discloses it is a write operation requiring editor+ role. States that likelihood and impact populate the 5×5 matrix. Lacks details on side effects, auto-calculation, or response format. With no annotations, more transparency expected.
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?
Single sentence with a parenthetical. Front-loaded with action. Could be slightly clearer on the parenthetical format, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Does not explain what happens upon creation (e.g., returns risk ID, triggers any workflow). No output schema provided, so description should at least hint at response. Missing details for a creation tool with 8 parameters.
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 covers all 8 parameters with descriptions (100% coverage). Description adds context that likelihood and impact together determine the risk matrix cell. Useful beyond schema alone.
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?
Clearly states action ('create') and resource ('new risk assessment in the risk register'). Includes role requirement. However, does not differentiate from sibling scf_create_custom_risk, which could cause confusion.
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?
Mentions required role ('editor+') and that it writes to the risk register. No explicit guidance on when to use this vs. scf_create_custom_risk or other risk tools. Implies use for standard risk matrix entries.
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 type of data returned (field-level changes, actor, timestamp, before/after values) but does not mention safety (read-only), permissions, rate limits, or error behavior. It is adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the tool's purpose and key details. It lacks any redundant information, though it could be slightly more structured (e.g., listing what is included).
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?
Without an output schema, the description provides a high-level summary of the output content but does not specify pagination behavior, order, or structure. The existence of limit and offset parameters implies paginated results, but this is not mentioned. Reasonable but incomplete.
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?
All three parameters have descriptions in the schema (org_id, limit, offset) with high coverage (100%). The description does not add meaning beyond what the schema already provides; it only describes the return format. Baseline 3 is appropriate as schema does the heavy lifting.
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 verb 'Get', the resource 'audit trail', and specifies it is for 'one organization' with details about what it contains: field-level changes, actor, timestamp, and before/after values. This distinguishes it from sibling tools that list entities or update them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives, such as when to use scf_list_controls vs this audit log tool. No explicit context for usage or exclusions is given, leaving the agent to infer from the name and siblings.
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?
Without annotations, the description should disclose behavioral traits. It indicates this is a read-only listing by detailing the returned fields. However, it does not mention pagination, ordering, or any limitations, which is acceptable for such a straightforward tool but could be more 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 extremely concise: two sentences totalling 20 words. It efficiently conveys the purpose, output fields, and optional search without redundancy.
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 one optional parameter and no output schema, the description covers the key aspects: what is listed, the fields returned, and the search option. It is complete enough for an AI agent to understand its basic usage, though details like result limits are omitted.
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 single parameter 'search' is described in the schema as a free-text search across names, vendors, and aliases. The tool description only says 'Optionally search by name', which is less accurate and adds no value beyond the schema. This inconsistency slightly reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing system-catalog templates. It specifies the output fields (slug, vendor, type, recipe maturity levels) and the optional search capability. However, it does not explicitly distinguish this list tool from the singular `scf_get_system_catalog_template` sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the optional search by name, providing basic usage context. But it lacks guidance on when not to use this tool or alternatives. For a simple list, this is adequate but not exemplary.
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 provided. The description indicates a read-only list operation but does not explicitly state behavioral traits such as authentication requirements, rate limits, or whether it is destructive. The schema includes pagination params, but the description does not clarify pagination behavior 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 a single sentence that front-loads the action and lists output fields efficiently. Slightly long due to field enumeration, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists fields returned, which is helpful given no output schema. However, it does not explain pagination parameters (limit/offset) present in the schema or mention default ordering beyond 'newest first'. Could be more complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description does not add extra meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists recent windowed AI assessments for an evidence item, ordered newest first, and enumerates the fields included. This distinguishes it from sibling tools like scf_get_window_assessment (single assessment) and scf_bulk_assess_windows (action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing assessments but does not provide explicit guidance on when to use this tool versus alternatives like scf_get_window_assessment for details or scf_list_evidence for evidence items. No when/not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses that the tool creates scoped-control entries, but it does not specify whether the operation is idempotent, what happens if controls are already scoped, or whether any data is destroyed. The write nature is implied but not detailed, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no redundant or extraneous information. Every phrase earns its place, clearly communicating the action, scope, and role requirement.
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?
Despite the tool's complexity (bulk write operation) and lack of output schema or annotations, the description is minimal. It does not cover potential side effects, error states, idempotency, or format of the response. Important contextual details for a bulk operation are missing, making the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (org_id, framework_id) having clear descriptions instructing the user to obtain values from other tools (scf_list_organizations, scf_list_frameworks). The tool description adds no further parameter-level information, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool bulk-scopes every control in a framework into the organization by creating scoped-control entries. It uses specific verbs ('Bulk-scope', 'Creates') and resource ('scoped-control entry for each control'), and it distinguishes itself from sibling tools like scf_batch_update_controls (update vs create) and scf_list_scoped_controls (list vs create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the required role ('write — editor+ role'), which is helpful, but it does not explicitly state when to use this tool versus alternatives like scf_list_scoped_controls (to check existing scoping) or scf_update_scoped_control (to modify individual scoped controls). No guidance on prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool returns and does not mention any side effects, authentication requirements, rate limits, or other behavioral traits. Minimal 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 a single, concise sentence (16 words) that front-loads the verb and resource. Every word adds value, and there is no redundancy or 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?
The description specifies what the tool returns but does not cover return format, prerequisites (e.g., valid theme_code), or error conditions. For a simple retrieval tool, the description is adequate but could be more complete in a complex context with no output schema.
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 100%, so baseline is 3. The description does not add additional meaning beyond the schema descriptions, which already explain parameter origins (e.g., obtain from scf_list_organizations). No extra guidance on parameter values or formats.
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 specifies the verb 'Get', the resource 'a single capability theme (KSI)', and the detailed output: full posture, multi-axis scores, band, and legacy posture_percentage. This distinguishes it from sibling tools like scf_list_capability_themes (list all) and scf_get_capability_theme_scorecard (scorecard version).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single capability theme's full details but does not explicitly state when to use this tool versus alternatives (e.g., scf_get_capability_theme_scorecard or scf_list_capability_themes). No 'when-not' or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It implies a read operation but does not explicitly state read-only, side effects, authentication requirements, or rate limits. The description lacks behavioral details beyond the core function.
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?
Single sentence, front-loaded with the core action, then specifics. Every word earns its place; no filler. Highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately explains the tool's purpose and output nature. However, it lacks details on return format, pagination, or field descriptions, which would improve completeness for an agent.
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?
There are zero parameters, so schema coverage is trivially 100%. The description adds value by clarifying the scope (across all organizations) and the nature of the result (prioritized pending items), which is useful context beyond 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 clearly states verb 'Get' and resource 'work queue', and elaborates on contents (prioritized tasks, assignments, action items) and scope (across all organizations). It is distinct from sibling tools like scf_get_notifications or scf_list_evidence_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. There are many sibling tools (e.g., scf_get_notifications, scf_list_evidence_tasks), but no comparative context or when-not-to-use advice.
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 that it returns tracking status, maturity level, and linked controls, implying a read operation. However, it does not mention pagination, rate limits, or whether it returns only active items. More behavioral details would be beneficial.
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 (two sentences) and front-loads the purpose. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description partially compensates by listing returned fields. However, it lacks information on pagination, sorting, or default behavior. Among many sibling evidence list tools, it does not help the agent choose correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions already in the schema. The description adds context about the overall return values but does not add new semantics specific to the parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'evidence items', and the context 'tracked against an organization's controls'. It also specifies what is returned (tracking status, maturity level, linked controls). However, it does not differentiate from sibling list tools like 'scf_list_evidence_catalog' or 'scf_list_evidence_gaps'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering by system, giving a specific use case. However, it provides no guidance on when to use this tool versus alternatives (e.g., listing evidence gaps or files). No explicit when-not or sibling comparisons.
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 bears the full burden of behavioral disclosure. It only mentions what fields are returned, but lacks details on side effects, authentication needs, rate limits, or ordering. This is insufficient for a mutationless list 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?
A single sentence that efficiently states the purpose and key return values. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters (org_id required, pagination, status filter) and no output schema. The description covers purpose and return fields but omits pagination behavior and filtering effects. It is minimally complete for a list operation.
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 100%, so the description's mention of returned fields adds value beyond the schema. However, it does not explain any parameters (like pagination or filtering). Baseline 3 is appropriate as per guidelines.
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 lists risk assessments in the risk register and specifies the returned fields (likelihood, impact, treatment status, linked controls). This distinguishes it from siblings like scf_get_risk (single risk) and scf_list_custom_risks (custom risks), providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like scf_get_risk or scf_list_custom_risks. Usage context is implied by the 'list' verb, but no guidance on filtering or when not to use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It mentions pagination and filters but does not state that the operation is read-only, non-destructive, or idempotent. It also doesn't describe what 'implementation status' means or how results are ordered, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading: the first states the main purpose, the second lists filter options. No redundant or irrelevant information. Every word serves a purpose.
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 9 parameters and no output schema, the description is adequate but incomplete. It covers purpose and filters but omits details on response structure, default sorting, how implementation status is represented, or whether results are paginated by limit/offset only. Given the complexity, more context is needed for full self-sufficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description enumerates filter categories (scope status, domain, framework, etc.) but does not provide additional semantic context beyond what the schema already offers for each parameter. No new constraints or usage patterns are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), identifies the resource ('controls scoped to the organization'), and includes implementation status, clearly distinguishing it from sibling tools like scf_list_controls (likely all controls) and scf_get_scoped_control (single control).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for listing scoped controls with filters, but lacks explicit guidance on when to use this tool versus alternatives (e.g., scf_list_controls for non-scoped views, scf_get_scoped_control for details). No when-not or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only lists the returned metrics without disclosing behavioral traits such as read-only nature, required permissions, potential side effects, or performance considerations. For a read operation, basic transparency is lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key information. Every word contributes to the purpose and outputs, with no unnecessary elaboration.
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 tool is simple with one parameter and no output schema. The description adequately lists the returned metrics for an aggregate summary. It could mention that results are read-only or dashboard-level, but overall it covers the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter org_id is already well-documented with a clear description and format. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves aggregate AI assessment metrics for the organization dashboard, listing specific outputs like total assessed, counts by status, unassessed count, average relevance score, and total cost. This differentiates it from sibling tools such as scf_get_evidence_assessment (individual) or scf_get_evidence_validation_summary (validation-focused).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for dashboard-level overview but does not explicitly state when to use this tool versus alternatives like scf_get_evidence_assessment or scf_get_window_assessment_summary. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as read-only nature, permissions, or side effects. Baselines rely on description to compensate, but it only states the retrieval action.
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?
Single sentence with front-loaded verb and resource, listing key fields concisely. No unnecessary words.
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?
Lists important fields returned (likelihood, impact scores, etc.) despite no output schema. Adequate for a detail retrieval tool, though could mention response format.
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 100% with descriptions for both parameters (org_id and risk_id). Description adds no extra meaning beyond the schema, so baseline 3 applies.
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?
Clear verb ('Get') and resource ('one risk assessment'), with specific fields listed (likelihood, scores, treatment plan, owner, review date). Distinguishes from sibling tools like scf_list_risks (list) and scf_get_risk_summary (summary).
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?
Description implies usage for detailed view but lacks explicit when-to-use or when-not-to-use guidance, and does not mention alternatives like scf_get_risk_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates 'ready for visualization' but does not disclose behavioral traits such as read-only nature, authentication requirements, or any side effects. Basic purpose is clear 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the main purpose, no wasted words. The description efficiently communicates what the tool does.
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 tool with no output schema, the description is adequate. It specifies the matrix size and intent. Could be more detailed about the return format (e.g., a 5x5 grid of values), but overall sufficient.
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 100%, so baseline is 3. The description does not add parameter semantics beyond what the schema provides (org_id is described in schema). No additional value.
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 returns the 5x5 risk matrix data, specifying the dimensions and purpose (visualization). It distinguishes from sibling tools like scf_get_risk (single risk) and scf_get_risk_summary (summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for visualization but does not explicitly state when to use this tool versus alternatives like scf_list_risks, scf_get_risk, or scf_get_risk_summary. No when-not guidance is 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?
No annotations are provided, so the description carries the full burden. It describes the read-only nature implicitly but doesn't disclose any behavioral traits such as auth requirements, rate limits, or error behavior. It adds minimal value beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource. No unnecessary words.
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 one parameter and no output schema, the description adequately explains what the tool returns. However, it could be more specific about the structure of the output. Given the tool's simplicity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter org_id, which includes a description referencing scf_list_organizations. The tool description does not add further context about the parameter, so baseline score of 3 applies.
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 verb 'Get', the resource 'organization's implementation statistics', and specifies the output: counts by status, completion percentage, and per-framework coverage. This distinguishes it from sibling tools like scf_get_organization or scf_get_evidence_assessment_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor when not to use it. There are no explicit context signals about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It correctly implies a read-only list operation and mentions pagination/filtering behavior, but does not explicitly state it is non-destructive, lacks authentication or rate limit context, and does not describe return format or any side effects. Basic behavioral info is present but 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?
Two sentences, front-loaded with purpose and key features. No unnecessary words. Every sentence 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?
Tool has 5 parameters, no output schema. Description explains output content (scoping status, implementation status, maturity level) and mentions pagination/filtering. Schema parameter descriptions reference obtaining org_id and theme_code from other tools. Missing details on return format or edge cases, but adequate for selective agent decision with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description mentions 'supports pagination and scope filtering' which mirrors schema parameter descriptions (limit, offset, scope_status). It does not add new meaning beyond the schema, so no improvement.
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 uses specific verb 'List SCF controls mapped to a capability theme', includes output fields (scoping status, implementation status, maturity level), and positions the tool as ideal for 'KSI drill-down' which distinguishes it from sibling list tools like scf_list_controls or scf_list_scoped_controls.
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?
Description implies usage context ('ideal for KSI drill-down') but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or prerequisites mentioned beyond what schema parameters provide.
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?
Discloses write operation, editor+ role requirement, async execution, and that items without tracking/frequency are skipped and reported. Given no annotations, this covers key behaviors well, though could elaborate on response contents beyond skipped_detail.
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?
Two sentences, no fluff. Each sentence adds essential information: core function in first, edge-case behavior in second.
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?
Adequate for a simple input tool with full schema coverage, but lacks details about what 'windowed' means, whether a job ID is returned, or how to track progress. Could be more informative for agents unfamiliar with the domain.
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?
Both parameters have descriptive schema coverage (100%). The description adds the skipped_detail behavior but not extra parameter context. Baseline 3 is appropriate since schema already documents parameters well.
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 'Queue windowed AI assessments for up to 25 evidence IDs' with a specific verb and resource. It mentions role and async nature, which helps differentiate from siblings like scf_bulk_assess_evidence, but does not explicitly contrast.
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?
Implies usage for windowed assessments and notes items without tracking/frequency are skipped, but does not explicitly state when to use this tool versus scf_bulk_assess_evidence or scf_trigger_window_assessment.
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 convey behavioral traits. It discloses that the tool lists a specific number of criteria and supports filtering and pagination. However, it does not mention idempotency, auth requirements, or other side effects. The description is adequate but not comprehensive.
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?
Two well-structured sentences: first states the core purpose, second adds key usage details. Every word earns its place, with no filler or redundant information.
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 discloses the number of criteria (5,736) and supports filtering and pagination. However, without an output schema, it omits details about the structure of each returned objective (e.g., fields like control_id, objective_text). For a list tool, this is moderately complete but could hint at the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by summarizing parameter usage (optional filter, free-text search, pagination) but does not provide new semantic information beyond the schema definitions.
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 verb 'List' and the resource 'SCF assessment objectives', specifying them as '5,736 test criteria used to evaluate control implementation'. It distinguishes from sibling tools like scf_list_controls by naming a distinct resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering by control ID, free-text search, and pagination, implying when to use these features. However, it does not contrast with sibling list tools (e.g., scf_list_controls) or provide explicit when-to-use or 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 provided; description adequately indicates it is a read-only listing with optional filters, but lacks details on authorization, rate limits, or default ordering.
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?
Two concise sentences with no extraneous information; purpose is front-loaded and filtering is briefly mentioned.
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 list tool with 3 optional parameters, the description covers basic functionality but omits output format, pagination, or default behavior, which would be helpful given no output schema.
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 100% with clear descriptions; the tool description only reiterates 'Optionally filter by assignee or status' without adding new semantics beyond 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?
Description states 'List evidence collection tasks — the work queue' which clearly identifies verb (list) and resource (evidence collection tasks), distinguishing it from sibling list tools.
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?
Description implies usage as a work queue tracker ('by whom, and by when') but does not explicitly state when to use vs. alternatives or when not to use.
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 supply behavioral insights. It mentions the write role and that only provided fields are applied (PATCH-like behavior), but lacks details on idempotency, error handling, or 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous words, effectively front-loading the purpose and key usage hint.
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 output schema and no annotations, the description covers the basics but does not specify return value, error scenarios, or prerequisites beyond the role. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no additional meaning beyond reinforcing the partial update behavior. Baseline of 3 is appropriate as the schema already documents all parameters adequately.
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 ('Update') and the resource ('vendor record'), and the parenthetical 'write — editor+ role' adds context. It distinguishes from sibling tools like scf_create_vendor and scf_get_vendor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating existing vendors and notes the required role, but does not explicitly state when to use this over alternatives like scf_create_vendor or provide 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?
With no annotations, the description carries full burden. It details the output metrics but does not disclose behavioral traits like read-only nature, required permissions, or side effects. This is minimally adequate for a simple GET-like 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?
Two sentences, front-loaded with the action and key outputs. No wasted words; every sentence adds value. Ideal for quick comprehension.
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 simplicity (one parameter, no output schema), the description covers purpose and outputs. However, it fails to clarify whether the results are for a specific theme or all themes, leaving a gap for a tool with that name.
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 mentions 'per-theme' metrics, but the only parameter is org_id (Organization UUID). This disconnect could confuse agents about how to specify the theme. The schema describes org_id well, but the description does not align with the parameter, reducing clarity.
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 the tool retrieves per-theme evidence metrics and lists specific outputs (controls with evidence, file counts, average relevance score, derived confidence). It distinguishes from sibling tools like scf_get_capability_theme_scorecard and scf_get_capability_theme by focusing on evidence posture.
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 a clear use case ('Use for KSI evidence dashboards'), indicating when to apply it. It lacks explicit exclusions or comparisons to alternatives such as scf_get_evidence_health, but the context is adequately stated.
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 that the tool returns a scorecard for all themes and lists the axes, but does not mention whether it is read-only, requires specific permissions, or has performance implications. It minimally adds context beyond what is inferable from the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both informative and front-loaded. No unnecessary words. Every sentence 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?
Given the tool's simplicity (one parameter, no output schema), the description sufficiently explains the return values (list of axes). It does not specify the output format or pagination, but for a single-parameter tool, the information is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (org_id) adequately described in the schema. The tool description does not add any additional meaning about the parameter beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'multi-axis KSI scorecard for every capability theme', and lists the specific scores returned (Implementation Coverage, Maturity, etc.). It distinguishes from siblings like scf_get_capability_theme (single theme) and scf_get_capability_theme_evidence_posture (single metric).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no guidance on when to use it vs. alternatives (e.g., scf_get_capability_theme). Usage context is implicit but not explicitly stated. No 'when not to use' or alternative tool mentioned.
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 full burden. It states 'Get' implying read-only and lists returned fields, giving a good overview. However, it does not disclose permission requirements, idempotency, or side effects beyond the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the tool's purpose and return value components. It is front-loaded and contains no extraneous 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?
Without an output schema, the description is the sole source for understanding return values. It lists four components, which is reasonably complete for a getter tool. However, it does not clarify how this tool differs from similar siblings, leaving the agent to guess the precise scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters already documented with guidance (org_id from scf_list_organizations, evidence_id from scf_list_evidence). The tool description adds no additional parameter semantics, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets one evidence item's collection maturity, listing the specific components returned (current level, contributing factors, upgrade potential, tracking state). This distinguishes it from siblings like scf_get_evidence_maturity (likely only level) and scf_get_evidence_upgrade_recommendations (focus on upgrade potential).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing what the tool returns, but provides no explicit guidance on when to choose this tool over alternatives. The agent must infer usage from the description alone.
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 provided; description indicates read-only operation ('Get') and lists return fields. Lacks details on authorization requirements, cost, or 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that efficiently communicates purpose and return content without redundancy.
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?
Adequately describes return value for a simple get tool with one parameter. Slight ambiguity about scope (overall vs per-framework) but consistent with tool name.
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?
Single parameter org_id with complete schema description (format, source). Description adds no additional semantics beyond schema; baseline 3 for high 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?
Clearly states 'Get the organization's evidence maturity summary' with specific components (average maturity score, automation percentage, distribution, improvement opportunities). Distinct from sibling tools like scf_get_evidence_item_maturity which operates at item level.
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?
Implied usage for retrieving organizational maturity summary, but no explicit when-to-use, when-not-to-use, or alternative tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the return content but does not disclose behavioral traits such as read-only nature, authentication requirements, or side effects. The verb 'get' implies read-only, but the description does not explicitly confirm.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the tool's purpose and return content without any unnecessary words. 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?
Given two parameters with good descriptions and no output schema, the description provides a clear idea of what is returned (target level, effort, impact, step-by-step actions). It is sufficiently complete for a simple retrieval tool, though it could mention if there are any limitations or pagination.
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 100%, and the description adds value by telling the agent where to obtain the parameter values: 'obtain from scf_list_organizations' for org_id and 'obtain from scf_list_evidence' for evidence_id. This goes beyond the schema and aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb and resource: 'get upgrade-path recommendations' for 'one evidence item's collection'. It also lists the return fields: target level, effort, impact, step-by-step actions. This distinguishes it from sibling tools like scf_get_evidence_maturity or scf_get_evidence_suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: 'the same guidance shown in the platform UI' suggests standard retrieval. However, it does not explicitly state when to use this tool over alternatives like scf_get_evidence_maturity, nor does it provide when-not guidance. Context is clear but lacks 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?
With no annotations provided, the description must fully disclose behavioral traits. It correctly indicates a read operation ('Get') and lists output fields, but fails to mention idempotency, caching, permissions, or rate limits. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and the key data returned. No extraneous details, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with three required parameters and no output schema, the description provides sufficient context about the returned data. It covers all key fields. Could mention error conditions or performance considerations, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; each parameter has a description in the schema. The tool description adds no additional meaning beyond listing the field types. Baseline of 3 is appropriate since the schema already documents the parameters adequately.
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 retrieves validation results for a single evidence file, listing the specific fields returned (status, completeness score, rule findings, source, timestamp). The name and description differentiate it from siblings like scf_get_evidence_validation_summary, which aggregates multiple files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific file and want its validation details, but it does not explicitly state when to use this tool over alternatives like scf_get_evidence_validation_summary or scf_get_evidence_health. No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. It explains what is returned but does not mention permissions, data freshness, rate limits, or that this is a read-only operation. The 'Get' verb implies read-only, which is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource, then lists the returned metrics. No redundant information or unnecessary words.
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 aggregate tool with one parameter and no output schema, the description is fairly complete. It tells what the tool returns and the required input. However, it could specify whether metrics are for all time or a default period, but this is a minor 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?
Schema description coverage is 100%, with org_id already documented. The description adds no extra meaning beyond listing returned metrics. Baseline score of 3 is appropriate as the schema handles parameter documentation sufficiently.
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 verb 'Get', the resource 'aggregate evidence validation metrics', and the context 'for the organization dashboard'. It lists the specific metrics returned, distinguishing it from sibling tools like scf_get_evidence_validation which likely returns per-file details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for dashboard-level summaries but does not explicitly state when to use this tool versus alternatives like scf_get_evidence_validation or scf_get_evidence_assessment_summary. No 'when not to use' or alternative names 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?
No annotations are provided, so the description carries full burden. It discloses that notifications include the listed types, implying a read operation. However, it does not disclose behavioral traits such as pagination, ordering, effects on read status, or rate limits. For a simple read tool, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the action and lists the content. Every word adds value with no redundancy or 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?
With two simple parameters, no output schema, and low complexity, the description is mostly complete. It could hint at pagination (e.g., 'paginated results') but is sufficient for an agent to understand the tool's core function. Missing details on ordering or default behavior are minor gaps.
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 100% with descriptions for both parameters (limit, unread_only). The tool description adds no additional meaning beyond the schema, merely listing notification types. Baseline 3 is appropriate as schema does the job.
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 uses a specific verb ('get') and resource ('the caller's notifications'), and lists concrete notification types (new assignments, comments, status changes, system alerts). This clearly defines the tool's purpose and distinguishes it from sibling tools that focus on other domains like organizations, evidence, or controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving notifications but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. While the sibling tools are mostly unrelated, context on when to prefer this tool (e.g., for user-facing alerts) is implicit.
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 indicates a read-only operation ('Get... detail') with no destructive side effects. However, it does not disclose authentication needs, rate limits, error handling, or performance characteristics. For a simple read tool, this is adequate but could be enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and clearly conveys the tool's purpose and key details. There is no wasted 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?
The description lists the specific types of data returned (subscription tier, member count, usage limits, settings), providing sufficient context for the agent to understand the output. Without an output schema, this enumeration is helpful and reasonably complete for a single-org detail tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage, including a clear description for org_id (UUID format and how to obtain it). The tool description adds no additional parameter information beyond what the schema already provides. Per guidelines, baseline is 3.
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 (Get), resource (one organization), and enumerates specific fields returned (subscription tier, member count, usage limits, settings). This distinguishes it from sibling tools like scf_list_organizations, which likely lists all organizations with less detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (retrieving detailed info about a specific organization) but does not explicitly state when to use this tool over alternatives like scf_list_organizations or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Indicates it's a poll operation and mentions queued jobs, but lacks details on response format, status values, polling interval, or idempotency. Adequate but not thorough.
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?
Two sentences, no filler. The essential purpose and usage instruction are front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more about what status information is returned (e.g., progress, error messages). This is a significant gap for a polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions that already explain how to obtain org_id and system_id. Description adds no further parameter context beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get' and the resource 'status of a queued AI recipe-generation job for a system'. The sibling tool scf_generate_system_recipes is directly referenced, establishing a clear 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?
Explicitly instructs to poll this after scf_generate_system_recipes, providing clear usage context. Does not specify when not to use or alternatives, but the context is sufficient.
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 convey behavioral traits. It mentions matching via catalog template, alias, or fallback and the return format, but does not explicitly state that the tool is read-only, nor discuss error conditions, authentication requirements, or rate limits. The description is partially 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 two sentences: the first states the primary action and matching logic, the second lists return fields. There is no redundancy, it is front-loaded with the purpose, and every sentence 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?
Despite lacking an output schema, the description specifies the return fields (matched_via, template summary, per-maturity-level recipe steps). Parameters are well-documented. The tool is simple and complete for its purpose, though it does not mention pagination or potential edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (org_id, system_id) are fully described in the input schema with instructions on how to obtain them. The description does not add additional semantic meaning beyond the schema; the baseline for 100% schema coverage is 3.
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 that the tool retrieves evidence-collection recipes for a system via catalog template, alias, or fallback, and lists the return fields. This distinguishes it from other tools like scf_get_system_catalog_template or scf_generate_system_recipes.
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?
Description implies usage context (retrieving recipes for a system) but does not explicitly state when to use this tool versus alternatives, nor when not to use it. No exclusion criteria or alternative tool references 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?
No annotations are provided, so the description must carry the full burden. It lists return fields but does not explicitly state that the operation is read-only, idempotent, or free of side effects. It also omits any authentication requirements or rate limits, though these may be assumed.
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 two sentences, front-loaded with the core action and followed by a concise list of return fields. No wasted words.
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, the description usefully enumerates the key return fields. However, it lacks details on error handling, pagination (not needed for single-object fetch), or what happens if the assessment is not found. Overall, it is sufficiently complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only reiterates that the tool gets by ID, which is already clear from the schema parameter 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 clearly states the action 'Get' and the resource 'one windowed AI assessment by ID', listing the specific fields returned. This distinguishes it from sibling tools like scf_list_window_assessments (list) and scf_get_window_assessment_summary (summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have a specific assessment ID, but does not provide explicit guidance on when to use this versus alternatives like scf_get_window_assessment_summary or scf_list_window_assessments. No exclusion criteria are mentioned.
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 burden. It discloses the return shape and contents but does not explicitly state read-only behavior, rate limits, or other behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose and return shape without redundancy. Every element is meaningful.
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?
Despite no output schema, the description outlines the return structure. For a simple list operation with well-documented parameters, it is nearly complete. Minor gaps like pagination are not critical.
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 100% and parameter descriptions are already clear. The description adds no extra meaning beyond the schema, meeting baseline expectations.
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 verb 'List' and the resource 'controls linked to a custom risk', differentiating from sibling tools like scf_list_controls (all controls) and scf_list_scoped_controls (scoped controls in a framework). It also mentions the specific return fields.
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?
No explicit guidance on when to use this tool versus alternatives. It implies usage for custom risks and hints at prerequisites by referencing how to obtain parameter values, but does not provide comparative context with siblings.
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 exist, so the description bears full burden. It discloses output fields and ordering but does not explicitly state read-only nature or any side effects. Adequate but could be more explicit.
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?
Two concise sentences: first states purpose and ordering, second lists included fields. No wasted words 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?
Given no output schema, the description covers key return fields and ordering. However, it lacks mention of pagination or limits, which would be helpful for a list endpoint. Still fairly complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters explaining how to obtain values. The tool description adds no additional parameter meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'vendor's AI security assessments', ordering 'newest first', and specifies included fields. This distinguishes it from sibling tools like scf_get_vendor_assessment (single assessment) and scf_trigger_vendor_assessment (trigger).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage requires a vendor ID but does not explicitly state when to use this tool versus alternatives (e.g., scf_get_vendor_assessment for a specific assessment). No when-not-to-use or context 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?
No annotations are provided, so the description must convey behavioral traits. It mentions 'newest first' ordering and the fields returned, but does not explicitly state that the operation is read-only, nor does it discuss side effects, authentication requirements, or rate limits. The description is moderately transparent for a list 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 two sentences, front-loading the main action and then detailing the output fields. Every word adds value; no redundant 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?
The tool has 4 parameters, no output schema, and no annotations. The description covers the output fields and ordering, but is missing an explicit statement that the operation is read-only. For a list tool with good parameter documentation, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with parameter descriptions (limit, offset, org_id, endpoint_id). The description adds marginal value beyond the schema by listing output fields, but does not enhance understanding of the parameters themselves. A baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List delivery logs for a webhook endpoint (newest first).' It specifies the resource (delivery logs), the scope (for a webhook endpoint), and ordering, making it distinct from sibling tools like scf_list_webhooks or scf_get_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (listing delivery logs) but does not explicitly state when to use this tool versus alternatives or when not to use it. Given the lack of sibling tools with similar functionality, this is adequate but not 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?
No annotations, so description carries burden. Reveals mutation and partial update behavior, and role restriction. However, does not disclose reversibility, error conditions, or idempotency.
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?
Two sentences, each essential. First states purpose and scope, second clarifies partial update. No 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?
Description covers purpose, partial update, and role requirement. Missing minor context like how to obtain identifiers, but schema already handles that. Appropriate for a simple update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description adds no additional parameter meaning beyond listing fields already in schema, so baseline 3.
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 'Update a custom risk definition's metadata' with specific fields (title, description, category) and role requirement. Distinguishes from siblings like create/delete by focusing on update.
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?
Mentions partial update ('Only provided fields are applied') but lacks explicit guidance on when to use this tool versus create/delete or prerequisites. Context is implied but not stated.
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 burden. It discloses the write operation, required role, and precondition (scoped control). However, it does not describe success behavior, idempotency, or possible error conditions, leaving some gaps for a transaction-agnostic agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence plus a brief parenthetical and a clarifying follow-up. Every word carries meaning, and the most critical information (action, role, precondition) 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 the simplicity of the operation and the absence of an output schema, the description adequately conveys the tool's purpose. However, it lacks details on return values, error handling, or confirmation behavior, which could be useful for an agent orchestrating a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already documented (e.g., 'obtain from scf_list_scoped_controls'). The description adds context about linking and scoping but does not enhance parameter understanding beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Link' and clearly identifies the resources ('scoped control', 'custom risk'), differentiating it from sibling tools like scf_remove_custom_risk_control and scf_list_custom_risk_controls. It also notes the write nature and required 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 states a clear prerequisite ('control must already be scoped'), but does not explicitly discuss when to use this tool versus alternatives or provide when-not guidance. The contextual implication is strong enough for an agent 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly indicates a read operation ('Get') and lists the specific outputs (current collector, capable systems, guidance). No side effects are mentioned, but the tool appears simple and non-destructive.
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?
Single sentence that efficiently communicates purpose, scope, and outputs. No redundant or extraneous information. Could be slightly restructured for clarity, but overall concise.
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 two parameters and no output schema, the description adequately covers what the agent needs to know: the purpose and the three return components. It is complete given the tool's low complexity.
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?
Input schema coverage is 100% and each parameter has a description (org_id and evidence_id with sourcing hints). The tool description adds little beyond 'for one evidence item', but the schema already provides adequate meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and the resource 'system-aware collection suggestions for one evidence item', and specifies the three types of information returned (current collector, capable systems, guidance). This distinguishes it from sibling tools like scf_get_evidence_upgrade_recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single evidence item, but does not explicitly state when to use this tool versus alternatives like scf_get_evidence_upgrade_recommendations or scf_get_evidence_maturity. No exclusions or when-not scenarios 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?
No annotations are present, so the description carries full burden. It indicates a read operation but does not disclose permissions, error handling, or side effects. The description is adequate but lacks depth beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (15 words) that is front-loaded and perfectly scoped. Every word adds value with no 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?
Given the tool has one parameter, no output schema, and no annotations, the description is complete. It clearly states what the tool returns (aggregate risk summary with breakdowns), fulfilling the agent's need to understand its output.
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 parameter org_id is fully described in the schema with format and a hint to obtain it from scf_list_organizations. The description does not add extra semantic value beyond the schema coverage (100%). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves an organization's aggregate risk summary and specifies what it includes (totals by severity, treatment status breakdown, trend data). This distinguishes it from siblings like scf_get_risk (single risk) and scf_list_risks (list of risks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for aggregate overview but does not explicitly state when to use it versus alternatives like scf_get_risk or scf_list_risks. No exclusion criteria or contextual guidance is 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?
With no annotations, the description carries the transparency burden. It indicates a read operation returning detailed fields, but omits potential error states, authentication needs, or rate limits. It adds value but does not fully disclose behavioral traits beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about 20 words, front-loading the key action and resource, then listing included fields. It is efficient and contains no redundant information.
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 partially compensates by listing several return fields, but it does not fully describe the response structure (e.g., single object, relationships). It is adequate but not exhaustive for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description's mention of 'by ID' adds little beyond what the schema already provides for each parameter (including sources like 'obtain from scf_list_organizations'). No additional semantic value is added.
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 ('Get'), the resource ('one vendor AI assessment'), and the retrieval criterion ('by ID'). It lists specific fields returned, distinguishing this from listing, latest, or status-only variants among siblings.
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 implies use when needing full details of a specific assessment by ID. It does not explicitly mention when not to use or name alternatives, but the context is clear enough. A 4 reflects that the guidance is present by implication but not contrasted with siblings.
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 full burden for behavioral disclosure. It states the tool returns status, started_at, completed_at, and error_message, which is helpful. However, it does not discuss potential errors (e.g., assessment not found), rate limits, or side effects. The description is adequate but lacks comprehensive 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 extremely concise: one sentence stating purpose, a list of return fields, and a one-sentence usage instruction. Every piece of information earns its place, with no wasted words. It is well-structured and 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?
For a simple polling tool, the description provides the essential context: when to use it and what it returns. However, it lacks details on possible status values, suggested polling interval, or error handling. Given the complexity is low, the description is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear source description (e.g., 'obtain from scf_list_organizations'). The tool description does not add any additional parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the job status of a queued vendor AI assessment, listing specific return fields (status, started_at, completed_at, error_message). It distinguishes itself from siblings by explicitly tying its use to polling after scf_trigger_vendor_assessment, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Poll this after scf_trigger_vendor_assessment.' This gives clear context and a sequential dependency, though it does not mention when not to use it or list alternatives. The guidance is sufficient for correct usage.
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 that the tool returns org-defined risks alongside static SCF catalog with auto-generated codes, implying a read operation. However, it does not specify permissions, pagination, ordering, or any side effects. The behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 18 words, front-loading the action. It is concise with no redundant information, and every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides adequate context about what is listed but lacks details on response structure, pagination, or sorting. For a list tool, this is acceptable 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 coverage is 100% with one parameter 'org_id'. The description adds value by stating 'obtain from scf_list_organizations', which guides the agent on how to get the parameter value. This provides meaning beyond the schema's format and pattern.
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 lists 'custom risk definitions' and distinguishes them from the generic SCF catalog with auto-generated codes. The verb 'List' and resource 'custom risk definitions' are specific, and it is easily differentiable from sibling tools like 'scf_list_risks' (all risks) and 'scf_create_custom_risk' (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing custom risks (as opposed to all risks via scf_list_risks), but it does not provide explicit guidance on when to use this tool vs. alternatives, nor does it mention when not to use it or any prerequisites. No alternatives are named.
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 describes a read operation (listing gaps) and does not mention any destructive behavior. However, it lacks details on performance, pagination, or any side effects, making it adequate 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 a single sentence that is front-loaded with the verb and resource. Every word is necessary; no fluff. Perfect conciseness.
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 simplicity (1 required param, no output schema), the description is adequate but could be more complete. It doesn't specify the return format (e.g., list of gaps with details, coverage percentage type). An output schema would help, but since none exists, the description falls slightly short of being 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?
Only one parameter (org_id) with 100% schema description coverage. The description in the schema provides guidance to obtain the UUID from scf_list_organizations, which adds value beyond the basic type and format. The tool description itself doesn't add further, but the schema coverage is high.
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 verb 'List' and the resource 'organization's evidence coverage gaps'. It explains what constitutes gaps (evidence required but not tracked) and mentions an overall coverage percentage, which distinguishes it from sibling tools like scf_list_evidence or scf_get_evidence_assessment_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. Although the purpose is clear, given the many evidence-related sibling tools, some guidance on when to use this gaps-focused tool would improve the score.
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?
Discloses key behavioral traits: async execution, editor+ role requirement, max batch size of 50, and return of count queued. No annotations exist, so description carries full burden; it effectively conveys safety and concurrency constraints.
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?
Extremely concise: three short sentences covering purpose, constraints, and return value. No redundant information; every sentence earns its place. Front-loaded with core action.
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 essential info: operation nature, input options, return format, and key constraints. Lacks mention of error handling or follow-up steps for the async job, but output schema is absent and tool complexity is moderate, so description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description restates parameters (evidence_id, file_ids, assess_unassessed) and adds the 'max 50' limit, but schema already provides detailed descriptions for each parameter (e.g., org_id source, file_ids purpose). Minimal additional semantic value beyond summarization.
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 the tool queues AI assessments for multiple evidence files, specifies it's a write operation with role requirement, async, and max 50. Distinguishes from siblings like scf_trigger_evidence_assessment by explicitly targeting bulk operations.
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?
Implies usage for bulk assessment of evidence files, but does not explicitly compare with similar tools (e.g., scf_trigger_evidence_assessment) or state when not to use it. Provides role requirement but no alternative 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 must cover behavioral traits. It states the tool retrieves data and lists return fields, but does not disclose idempotency, potential errors, permissions, or side effects. Basic read behavior is implied by 'Get', but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the primary action and resource. Every part adds value without redundancy, making it highly 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 simple retrieval tool with one parameter and no output schema, the description covers the main purpose and specifies returned data fields. It could mention error conditions or response format, but overall it provides sufficient context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a detailed description of scf_id including format examples. The tool description adds no further meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get a single SCF control by ID') and identifies the specific resource. It lists the return contents (description, mapped frameworks, assessment objectives, linked evidence items), distinguishing it from sibling tools like scf_list_controls.
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 implies usage for retrieving a specific control by ID, but lacks explicit guidance on when to use this versus alternatives (e.g., when to use scf_list_controls or scf_get_scoped_control). No exclusion criteria are provided, but the purpose is clear enough 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.
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 disclosing behavioral traits. It indicates the tool is read-only ('get'), but does not discuss authentication needs, rate limits, or side effects. For a simple retrieval, this is adequate but not above minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 12 words. Every word adds value with no redundancy or 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?
Given the tool is simple (0 parameters, no output schema), the description lists the main return fields, which provides adequate context. However, it could detail the structure of nested fields (e.g., organization memberships) for full completeness.
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 tool has no parameters and schema coverage is 100%, so the description adds no parameter semantics beyond the schema. Per rubric, baseline is 3 for high 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?
The description clearly states the tool retrieves the authenticated caller's profile and specifies the fields returned (name, email, organization memberships, per-org role). This distinctively separates it from sibling tools like scf_get_organization or scf_list_members, which handle other entities.
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 implicitly clarifies usage: use when you need the caller's profile. No explicit exclusions or alternatives are mentioned, but the context is clear enough for an agent to infer applicability.
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 full burden. It discloses the return of metadata and a pre-signed URL with expiry, giving some behavioral insight. However, it omits details like authentication requirements, error handling, or read-only 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 two concise sentences (21 words) with front-loaded key information. Every sentence adds value; no redundancy.
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 3 required params and no output schema, the description adequately explains the tool's function and what it returns (metadata + download URL with expiry). It could mention potential requirements like file existence or permissions, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already well-described (e.g., 'obtain from scf_list_evidence_files'). The description adds no further parameter-level meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves metadata and a pre-signed download URL for a single evidence file, with a specific 15-minute expiry. It distinguishes itself from listing tools like scf_list_evidence_files by focusing on a single file with download capability.
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 advises using the tool to inspect or retrieve a specific uploaded artifact, providing clear context. It does not explicitly mention when not to use or alternatives, but the sibling tools list implies other tools for listing or revalidation.
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 burden. It discloses the returned data (RAG status, etc.) and 404 behavior, but omits details on error handling for invalid vendor/org, permission requirements, or explicit read-only nature. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states purpose, return fields, and a key error condition. No redundant words, well 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?
Given no output schema and no annotations, the description covers the core purpose and return fields, plus a notable error case. It lacks details on response structure (e.g., data types of fields) and permission requirements, but it is reasonably complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add parameter semantics beyond the schema's descriptions (which tell how to obtain IDs). It provides no additional context on format or constraints.
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 verb 'Get' and the resource 'vendor's latest completed AI security assessment'. It lists the return fields and error condition (404), distinguishing it from siblings like scf_get_vendor_assessment (by ID) and scf_list_vendor_assessments (list).
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 implies usage for retrieving the latest completed assessment and mentions a 404 when none exists. However, it does not explicitly guide when to use this tool versus alternatives like scf_get_vendor_assessment or scf_list_vendor_assessments, though 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.
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 that the tool returns 'full detail' and lists some contents, but does not explicitly state it is read-only, lacks side effects, or discuss permissions or error cases. For a simple GET-like operation, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 18 words that efficiently communicates purpose and contents. No superfluous information is included.
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 fetch tool with one parameter and no output schema, the description covers what the tool does and where to get the input. It lacks explicit mention of error handling or return format, but lists key return fields. The absence of an output schema is partially compensated by the description of contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, describing the 'slug' parameter as 'Template slug — obtain from scf_list_system_catalog'. The tool description does not add additional meaning beyond this schema description, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get one system-catalog template by slug with full detail', specifying the verb (Get) and resource (system-catalog template). It lists the included details (aliases, recipes with attributes), which distinguishes it from sibling tools like scf_list_system_catalog, which likely lists templates without full detail.
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 explains that the slug is obtained from scf_list_system_catalog, implying a prior list step. It does not explicitly state when not to use this tool or name alternatives, but the single-parameter fetch pattern makes usage context clear. A slightly higher score would require explicit exclusion of other 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?
No annotations are provided, so the description must carry the burden. It reveals the polling nature ('Poll this after'), indicating an asynchronous operation. However, it does not disclose expected statuses, error conditions, or whether the operation is idempotent. More detail would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence plus a short instruction. Every word adds value, with no redundancy. It is easy to parse and front-loaded with the primary 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 no output schema, the description lists the return contents (breach history, known vulnerabilities, security posture analysis), which adequately informs the agent about what to expect. It could be more specific about the structure, but the list is sufficient for a polling 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?
Schema description coverage is 100%, with both parameters having descriptions that tell the agent to obtain UUIDs from other tools. The tool description adds no extra parameter context beyond that baseline, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get', the resource 'vendor research result', and specifies contents: breach history, known vulnerabilities, and security posture analysis. It also links to the sibling tool scf_trigger_vendor_research, distinguishing its role as a retrieval step after triggering.
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?
Explicitly says 'Poll this after scf_trigger_vendor_research', providing clear usage context and sequencing. However, it does not mention when not to use or alternative tools, but the context and sibling list make it sufficiently 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 provided, so the description must carry the full burden of behavioral disclosure. It states the operation is a read and specifies the output fields, but it does not mention potential limitations (e.g., performance impact, data freshness, rate limits, or whether the aggregation is real-time or cached). This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and lists key outputs. Every phrase adds value, with no redundancy or unnecessary elaboration.
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 the tool's simplicity (one parameter, no nested objects), the description is fairly complete. It details the return values (total windows, status counts, average relevance, total cost), which compensates for the lack of an output schema. It lacks explicit mention of the data source or any caveats, but for a summary endpoint this is sufficient.
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 only parameter, org_id, is documented in the input schema with a clear description and format. The description adds no additional meaning beyond what the schema already provides. With 100% schema description coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: retrieving aggregate windowed-assessment metrics for the organization dashboard. It lists the exact metrics returned (total windows, status counts, average relevance, total cost) and distinguishes itself from sibling tools like scf_get_window_assessment, which operates at the individual assessment level.
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 implies this tool is for generating dashboard-level summaries but does not explicitly state when to use it over alternatives. It lacks guidance on exclusions (e.g., not for detailed per-window data) or context like recommended use cases. However, the purpose is clear enough that an agent can infer appropriate usage.
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 full burden. It notes 'list' and 'reference catalog' implying read-only, and mentions search/pagination. Lacks explicit statements about idempotency, authentication, or no 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, concise and front-loaded. First sentence states core purpose and key fact (272 evidence types), second adds search/pagination. No wasted words.
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 search/pagination, the description covers purpose, count, and features. Lacks mention of output format or pagination defaults, but schema covers those.
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 100% and all three parameters are already described in the input schema. The description adds 'free-text' and 'pagination' context but does not add meaning beyond 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?
Clearly states it lists evidence items from the SCF reference catalog, specifies the exact count (272 standard types), and distinguishes from sibling 'scf_list_evidence' (user evidence) by using 'reference catalog'.
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?
Mentions free-text search and pagination, and the phrase 'reference catalog' implies use for predefined evidence types. However, no explicit when-not or alternative sibling 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 provided, so the description carries the full burden. It correctly indicates a read-only operation (list), specifies ordering and returned fields. It does not disclose pagination or authorization details, but for a simple list tool this is largely sufficient.
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?
One sentence that front-loads the purpose and ordering, then lists returned fields. No wasted words. Structure is optimal.
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 returned fields and ordering. It does not mention pagination or total count, which would be useful, but for a straightforward list it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (org_id) with 100% schema coverage. The schema description already explains it. The tool description adds no additional parameter context beyond stating 'organization's webhook endpoints'.
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 (list), resource (webhook endpoints), scope (organization), ordering (newest first), and returned fields (name, status, delivery count, secret prefix). It distinguishes from siblings like scf_get_webhook, scf_create_webhook, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when listing webhook endpoints for an organization, but does not provide explicit when-to-use vs alternatives. Among sibling webhook tools (create, get, delete, etc.), no guidance is given on choosing this list operation over others.
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 adequately discloses it is a write operation (editor+ role), async, and returns 422 for missing data. It does not cover rate limits or idempotency but is transparent about key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence plus a short error condition. Every word adds value: verb, target, role, async, error condition. No wasted 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?
Given no output schema, the description covers key aspects: what it does, async nature, role requirement, and error condition. It does not mention response format or follow-up retrieval, but overall adequately complete for a trigger tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions already explaining parameters. The description adds some context (e.g., org_id from scf_list_organizations, evidence_id needs tracking/frequency) but does not significantly enhance beyond schema. Baseline 3.
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 it queues a windowed AI assessment scoring files as a portfolio, with role and async behavior. It distinguishes from sibling tools like scf_trigger_evidence_assessment and scf_bulk_assess_evidence by emphasizing 'windowed' and 'portfolio'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions preconditions (tracking/frequency must exist) and error condition, but does not explicitly compare with sibling tools like scf_bulk_assess_windows. Usage context is implied but not clearly delineated.
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?
Without annotations, the description effectively discloses that this is a write operation, is asynchronous, returns HTTP 202, and requires editor+ role. These details go beyond basic purpose and help the agent understand 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 concise (one sentence plus parenthetical) and front-loaded with the core purpose. Every part adds value, though the parenthetical could be slightly more integrated.
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 the async nature, lack of annotations, and no output schema, the description covers essential aspects: initiation, role, async behavior, and polling. It does not detail response format, but that is acceptable without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptive explanations (e.g., 'obtain from scf_list_organizations'). The description does not add additional meaning to the parameters beyond what the schema already provides, but the schema itself is sufficient.
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 ('Queue AI generation') and resource ('evidence-collection recipes for a system'). It distinguishes this tool from siblings like scf_get_system_recipes (retrieval) and scf_get_recipe_generation_status (polling) by focusing on initiating generation.
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 specifies the required role ('editor+'), async nature, and next step ('Poll scf_get_recipe_generation_status for progress'). While it doesn't explicitly list when not to use it, the context and sibling tools provide sufficient 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. The description indicates a read operation (get) which is generally safe and non-destructive. It discloses the types of details returned (delivery stats, allowed evidence IDs, rate-limit configuration) but does not mention any side effects, required permissions, or rate 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 a single 14-word sentence that is direct and free of unnecessary words. Every part 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?
Given no output schema, the description sufficiently indicates the return content (delivery stats, allowed evidence IDs, rate-limit configuration). Parameter descriptions include guidance on obtaining IDs. A hint about the output structure or expected response size would improve completeness, but current level is adequate.
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?
Both parameters have descriptions in the schema that add context beyond name and type: org_id includes 'Organization UUID — obtain from scf_list_organizations' and endpoint_id includes 'Webhook endpoint UUID — obtain from scf_list_webhooks', providing clear guidance on how to obtain valid values. Schema coverage is 100%.
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 'Get' and the resource 'one webhook endpoint's detail', and specifies what details are returned: 'delivery stats, allowed evidence IDs, and rate-limit configuration'. This distinguishes it from sibling tools like scf_list_webhooks (list all) and scf_create_webhook (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives or provide prerequisites. The context implies it is for retrieving a single webhook by ID, but no guidance on when not to use or which sibling tool to use instead is given.
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. The verb 'list' implies a safe read-only operation, and the description adds that it returns a set of themes. However, it does not explicitly state that the tool is non-destructive or require authentication, which would be beneficial.
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 two concise sentences. The first sentence states the core purpose, and the second adds context. No extraneous information. Every sentence earns its place.
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 simplicity (one parameter, no output schema, no annotations), the description is complete: it explains what the tool does, what themes are, and how they relate to controls. An agent has enough information 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'org_id'. The schema already provides a description (UUID format, obtain from scf_list_organizations). The tool description does not add any new semantic information about the parameter, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List an organization's 11 KSI capability themes' with a specific verb and resource. It clearly distinguishes from sibling tools like 'scf_list_capabilities' and 'scf_get_capability_theme' by noting that it lists exactly 11 themes and provides context about their purpose (grouping NIST 800-53 controls for high-level posture view).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to list all capability themes for an organization. It implies this is for obtaining a high-level posture view. While it does not explicitly mention when not to use it or name alternatives, the context is sufficient for an agent to differentiate from get operations on single themes.
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 pagination and optional filtering, indicating a read-only operation. No destructive behavior is implied, though details like ordering or total count are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose, options, and behavior with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not describe the response structure (e.g., fields returned, pagination metadata). For a list operation with multiple parameters, the description could provide more detail about what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters with details. The description only summarizes filters and pagination, adding minimal extra meaning beyond 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 clearly states the action ('List'), the resource ('third-party vendors'), and the context ('TPRM registry'). It distinguishes from sibling tools like scf_get_vendor (retrieves a single vendor) and scf_create_vendor (creates a vendor).
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 implies usage for listing vendors with filters, and the sibling tool names (e.g., scf_get_vendor, scf_create_vendor) provide context for when to use each, but no explicit when-not or alternatives are stated.
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 discloses important behavior: batch size limit, transaction semantics, required role, and the lowercase status requirement. It does not detail rollback behavior or partial failure consequences, which would improve 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?
Single sentence that conveys all critical information efficiently, front-loaded with the action and scope. No redundant or filler content.
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 batch update tool without output schema, the description covers key aspects: batch size, transaction atomicity, role requirement, identifier format, and status case. Missing details about the return value (e.g., success/failure counts) but still adequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds batch size limits and notes the required scf_id in each operation, but does not significantly deepen understanding beyond the schema's property 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 clearly states the tool performs a batch update of scoped controls, specifying the maximum quantity (500) and transaction nature. It distinguishes from the sibling scf_update_scoped_control, which handles single updates.
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 the required role ('editor+'), case formatting for status, and the transaction guarantee. While it doesn't explicitly contrast with alternatives, the batch vs single update distinction is implicit from the tool name and sibling context.
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 full burden. It discloses role requirement and auto-scoring side effect, but does not mention response format or other side effects. Acceptable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words, front-loaded with key action and role requirement. Efficiently communicates essential 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?
Given 8 parameters, 100% schema coverage, and no output schema, the description covers role and auto-scoring. Missing return value info, but overall adequate for a create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema descriptions are detailed. Description adds context about role requirement and auto-scoring, but does not enhance per-parameter semantics beyond what schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (create), resource (vendor in TPRM registry), and adds role requirement and auto-scoring behavior, distinguishing it from sibling tools like scf_list_vendors and scf_update_vendor.
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?
Explicitly mentions required role ('editor+'), implying when to use (create a new vendor) and implicitly not for updating or reading. However, no explicit alternative or exclusion is stated.
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?
Discloses admin role requirement and the irreversible retrieval of the secret (write operation). Without annotations, the description carries the full burden and covers key behavioral traits, though could mention idempotency or side effects if any.
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?
Two sentences, fully front-loaded with purpose, then essential behavioral warning. No wasted words.
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 main action, critical return value warning, and role requirement. Lacks output format or error behavior, but given no output schema and 5 parameters, it is sufficiently complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the schema already provides detailed descriptions for each parameter. The main description adds no additional semantics for parameters beyond the secret return behavior.
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 the action 'Create', the resource 'webhook endpoint', and the context 'for evidence-inbox ingestion (write — admin role)'. Distinct from sibling tools like list, get, delete, rotate.
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 critical 'store it immediately; it cannot be retrieved later' guidance for the HMAC secret. However, does not explicitly state when to use this tool vs alternatives, though sibling tools are mostly different operations.
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 takes on the full burden. It discloses the destructive nature ('destructive write'), irreversibility, required role, and the cascading deletion of assessment records and control mappings. This provides sufficient behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys all essential information. It is front-loaded with the primary action and quickly details what is deleted, the role requirement, and the irreversible nature—no unnecessary words.
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 the tool's destructive nature and lack of output schema or annotations, the description is fairly complete. It covers what is deleted, the role needed, and irreversibility. However, it could mention that the operation cannot be undone or list any prerequisites (e.g., risk must exist).
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 100% with descriptions already present for both parameters. The description does not add additional semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'custom risk definition', and it specifies the scope: 'its assessment record, and every control mapping'. This distinguishes it from sibling tools like scf_create_custom_risk or scf_update_custom_risk.
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 implies when to use this tool—when you need to permanently remove a custom risk and its associated data. It also mentions the required role ('editor+'), but does not explicitly state when not to use it or provide alternative tools for non-destructive actions.
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 the tool returns an AI assessment with status, implying potential asynchronicity, and specifies audit metadata. This is sufficient for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence plus a short polling instruction, with no fluff. Every part 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?
The description covers the return value sufficiently for a read tool, given no output schema. It mentions polling after trigger, but could include more on error states or what to do if not ready. Overall adequate.
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 100% with clear parameter descriptions linking to other tools. The tool description does not add extra parameter semantics beyond the schema, meeting the baseline expectation.
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 it retrieves the AI assessment for an evidence file, listing specific output components (status, relevance score, structured findings, summary, audit metadata). It distinguishes from siblings like scf_get_evidence_assessment_summary by offering the full assessment and implies polling after trigger.
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 advises to poll after scf_trigger_evidence_assessment, providing clear usage context. It does not explicitly mention when not to use this tool or alternatives like the summary tool, but the polling instruction is effective.
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 full burden but only describes what the tool returns, not side effects or non-destructive nature. It does not contradict any annotations. The transparency is adequate but lacks explicit read-only hint or preconditions.
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?
Two sentences, front-loaded with the main purpose and result. No unnecessary words. Each sentence adds essential information (detail content and identification method).
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 get operation with two parameters and no output schema, the description covers what is returned and how to identify the record. It is sufficiently complete, though a note about read-only nature or return format could enhance it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by clarifying that scf_id is not the UUID but a DOMAIN-NN format identifier, which helps avoid common misuse. This goes beyond the schema's 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 verb 'Get', the resource 'scoped control', and specifies the detail level including owner, implementation notes, evidence links, and audit history. It distinguishes from listing by mentioning 'in detail' and clarifies identification method (by scf_id, not UUID), differentiating from other get 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: to retrieve a single scoped control with full details. It specifies identification by scf_id rather than UUID, which contrasts with list operations. However, it does not explicitly state when not to use or list alternative tools like scf_get_control, so slightly less than perfect.
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, description carries full burden. Explains cursor-pagination, worst-band-first sorting, and filter usage. Does not mention auth, rate limits, or side effects, but covers key behaviors.
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?
Two sentences, front-loaded with purpose, second sentence covers pagination and filters. No fluff, every sentence 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?
Covers pagination, sorting, and filtering well. Missing output schema, but 'rolled-up assessment composites' gives enough context. Adequate for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description summarizes filter params but does not add new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists rolled-up assessment composites for the org, with pagination and sorting. Differentiates from scf_get_control_assessment_composite (singular) and other list 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (list composites for org), pagination behavior, and filter options. Lacks explicit exclusions but sibling names imply alternatives like scf_get_control_assessment_composite.
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 full burden. It clearly states that the control and risk remain after unlinking, and that only the mapping is removed. It also mentions the required role. It does not cover error cases or idempotency, but the core behavior is well-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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the key action, and includes essential context (role requirement, non-destructive nature). No unnecessary words.
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 the simple action and no output schema, the description adequately explains the tool's purpose and side effects. It lacks information on return values or error handling, but for a straightforward unlinking operation, the coverage is sufficient.
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 100% with descriptions for all three parameters (org_id, scf_id, risk_code) that explain their format and how to obtain values. The tool description itself adds no additional parameter details, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Unlink a scoped control from a custom risk' and uniquely identifies the resource. It distinguishes from siblings like scf_add_custom_risk_control by noting that only the mapping is removed, not the control or risk.
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 implicitly tells when to use (to unlink a control from a risk) and mentions the required role (editor+). It does not explicitly state when not to use or list alternatives, but the sibling context makes it clear that scf_add_custom_risk_control is the inverse.
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, the description fully discloses key behaviors: immediate invalidation of old secret, one-time return of new plaintext secret, and required admin role. This is comprehensive 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with action and resource, followed by behavioral details. No redundant information. Each sentence contributes 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?
The description covers core behavior, return value, and access level. It lacks error handling or prerequisite details, but for a simple rotation tool with no output schema, it is sufficient. Could mention what happens if endpoint is missing.
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 100% with clear descriptions. The description does not add meaning to individual parameters but provides context about the operation. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rotate HMAC signing secret), the resource (webhook endpoint), and key attributes (admin role, immediate invalidation, one-time return). It distinguishes from sibling tools which are mostly read or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions admin role and write operation, implying it's for authorized users, but does not explicitly state when to use vs alternatives or when not to use. Siblings include other webhook tools but no other rotation tool, so guidance is implicit.
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 bears full burden. It discloses key behavioral traits: it's a write operation requiring 'editor+ role', asynchronous (HTTP 202), and returns 'assessment_id + job_id'. It also mentions replacing a deprecated trigger, adding lifecycle context. It could improve by noting idempotency or error states, but 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 extremely concise: two sentences with no wasted words. It front-loads the core purpose, includes behavioral notes, and directs to the follow-up tool. Every sentence 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?
Given the tool has 6 parameters and no output schema, the description covers purpose, async nature, role requirement, HTTP status, return fields, and polling advice. It lacks details on error conditions or prerequisites, but is fairly complete for a trigger tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 6 parameters described in schema). The description does not add additional parameter-level meaning beyond stating return fields. Baseline 3 is appropriate as the schema already documents 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 the tool's purpose: 'Queue an AI vendor security assessment (write — editor+ role, async, HTTP 202).' It specifies the action (queue a vendor assessment), the resource (vendor security assessment), and distinguishes itself from siblings by noting it 'Replaces the deprecated DPSIA trigger' and directing to poll a specific tool for 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?
The description provides context for when to use: it's for triggering a vendor security assessment and replaces a deprecated trigger. It also advises polling 'scf_get_vendor_assessment_status' for follow-up. However, it does not explicitly state prerequisites (e.g., vendor must exist) or when not to use, but the purpose 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 full burden. It discloses write operation, role requirement, async nature, output (task ID), and next step. It does not cover destructive potential or idempotency, but for a queue action this 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?
Two sentences, no redundancy. Each piece of information earns its place: role, async nature, data sources, output, and next step.
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, the description covers the tool's behavior thoroughly. It explains what is checked and the follow-up action. Missing details like rate limits or error handling are minor for a simple trigger tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions already explain their purpose and sourcing. The main description adds no additional semantic information beyond the schema, so baseline score of 3 applies.
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 verb ('Queue AI security research'), resource ('vendor'), async behavior, role requirement, and data sources checked. It distinguishes itself from the sibling scf_get_vendor_research by explicitly mentioning polling that endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for triggering async vendor research, requires editor+ role, and returns a task ID to poll. It does not explicitly state when not to use it or list alternatives, but the context is sufficient given the sibling set.
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 full burden. It discloses it's a write operation, required role, identifier rule, and partial update behavior. However, it does not mention potential errors or 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences that front-load the core action and resource. Every sentence adds distinct value: action+role, identifier hint, and update behavior. No redundant or extraneous 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?
Given the tool's complexity (11 parameters, no output schema), the description provides essential context but does not mention that the tool only applies to existing scoped controls or what the response format is. For a mutation tool without output schema, this is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters, so baseline is 3. The description adds value by explaining the update semantics ('Only provided fields are applied') and reinforcing the scf_id usage, which clarifies parameter intent beyond 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 clearly states the action ('Update'), the resource ('scoped control's implementation fields'), and includes role requirements ('write — editor+ role'). It also specifies the identifier type ('scf_id, not UUID'), distinguishing it from tools using UUIDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions role requirement and partial update behavior ('Only provided fields are applied'), but does not explicitly state when to use this tool versus alternatives like scf_batch_update_controls or scf_scope_framework. Context for when not to use is missing.
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 that the tool returns 'framework identifiers and display names,' but does not mention any behavioral traits such as pagination, authentication requirements, or performance characteristics. For a simple listing tool, this is adequate but minimal.
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 two sentences, no redundant information, and front-loads the purpose. Every sentence adds value.
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 list tool with no parameters and no output schema, the description adequately specifies what is returned (identifiers and display names). It is complete given the tool's simplicity and the context (many sibling tools with more complex behaviors).
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% (vacuously). The description does not need to add parameter information. The baseline score of 4 for zero parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every compliance framework mapped in the SCF catalog, with specific examples (NIST 800-53, ISO 27001, etc.). It distinguishes from siblings that focus on specific frameworks or scoping.
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 implies when to use this tool (to get a list of all frameworks), but does not explicitly state when not to use it or provide alternatives among the many sibling tools. However, given the tool's simplicity and clear purpose, this is a minor gap.
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 full burden. It discloses the write operation ('write'), async behavior, and the return of a pending record. It instructs polling for status. It does not detail failure modes or side effects, but the key behaviors are covered adequately.
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?
Two sentences with critical information front-loaded: purpose, write operation, role, async, return, and next steps. No filler. Highly efficient.
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 lack of output schema, the description adequately explains the return (pending record) and the follow-up action. It covers the core workflow, async behavior, role requirement, and resource constraints. All necessary context for an agent 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema provides (e.g., parameter sources are already in schema descriptions). The optional assessment_source is not elaborated. Thus, it meets but does not exceed the baseline.
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 explicitly states 'Queue an AI assessment of a single evidence file', clearly identifying the verb, resource, and scope. It distinguishes from siblings like scf_bulk_assess_evidence by specifying 'single', and mentions the async nature and the polling 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 advises when to use (queue assessment) and what to do next (poll scf_get_evidence_assessment). It implies a single-file use case, differentiating from bulk. It also notes the required role ('editor+'), providing context. However, it does not explicitly list when not to use or compare alternatives in detail.
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 full burden. It discloses it is a write operation requiring editor+ role and performs partial updates. It does not detail error handling or response format, but it is sufficient for common understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes all essential information: action, role, optional behavior. No redundant text.
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 10 parameters and no output schema, the description is somewhat brief. It lacks information about return value, error handling, or prerequisites (e.g., system must exist). It is adequate but could be 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 coverage is 100% so baseline is 3. The description adds value by clarifying that updates are partial ('only provided fields are applied'), which is not obvious from the schema alone. It also mentions the role requirement.
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 it updates an existing system record, specifies the write operation and required role ('editor+'), and distinguishes from create/list tools by the 'update' verb and partial update behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes that all fields are optional and only provided fields are applied, giving clear usage guidance. However, it does not explicitly exclude when not to use (e.g., for creating new systems) or compare with siblings like scf_create_system.
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?
No annotations provided, so description carries full burden. Discloses that it's a destructive write, soft-deletes marking inactive, requires admin role, and that deliveries will return 403 while record remains for audit. This is comprehensive.
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?
Single sentence packed with all essential information: action, soft-delete behavior, destructive write, role requirement, future effect, and audit retention. No wasted words.
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 delete operation with clear schema, the description covers purpose, side effects, and requirements. Missing return value info, but output schema is absent. Otherwise very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters already described. The tool description does not add extra meaning to parameters, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Revoke a webhook endpoint' with a specific verb and resource. Explains it's a soft-delete and distinguishes from other webhook tools like scf_get_webhook or scf_list_webhooks.
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?
Explicitly mentions 'admin role' requirement and the effect (future deliveries return 403). However, it does not explicitly contrast with alternatives like permanently deleting, though it's implied by 'soft-delete'. Still provides clear context.
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 provided; description carries burden. Discloses a key behavioral trait: 404 returned if composite row does not exist (async). Also notes response includes status band and gaps. Does not explicitly state read-only or side effects, but implies idempotent read. Adequate for safe usage.
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?
Single sentence, highly concise, yet packs all key information: action, resource, return fields, and error condition. No wasted words.
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, description provides sufficient detail about response (composite score, status band, evidence IDs, gaps, per-window detail). Mentions 404 error. Lacks info on authentication or request headers, but standard for API tools. Good overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both params (org_id: UUID from another tool; scf_id: DOMAIN-NN format). Description minimally adds context beyond schema, but that's acceptable since schema already clarifies. No param info missing.
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 uses specific verb 'Get' and identifies the exact resource 'rolled-up assessment composite for one SCF control'. It lists return fields (composite score, status band, evidence IDs, gaps, per-window detail) and distinguishes from siblings like 'scf_list_control_assessment_composites' which returns a list.
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?
Clearly states what the tool returns and its single-control scope. Implicitly, use when you need detailed composite for one control rather than a list. Lacks explicit when-not-to-use or alternative tool reference (e.g., 'for a list use scf_list_control_assessment_composites'), but still 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?
No annotations provided, so description carries full burden. It discloses pagination via offset/limit, returned fields, and filtering capabilities. It doesn't mention destructive effects, auth needs, or rate limits, but as a read-only listing tool, this 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?
Two sentences, front-loaded with main purpose and returned fields, then filtering options. No redundant 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?
No output schema, but description specifies returned fields. Covers pagination and filtering. Could mention default sorting or order, but overall adequate for a listing tool with 5 optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds value by explaining that domain and framework values can be obtained from scf_list_domains and scf_list_frameworks respectively, and by summarizing the returned 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 it lists SCF security controls from a reference catalog, specifies returned fields (SCF ID, title, description, mapped frameworks), and mentions filtering. It distinguishes itself from sibling tools like scf_list_domains and scf_list_evidence_catalog by focusing on controls.
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?
Description explains filtering by domain, framework, or free-text search, implying use cases for browsing the reference catalog. It doesn't explicitly exclude other tools or mention when not to use, but context among siblings is clear enough.
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, the description fully discloses expected behavior: returns filename, content type, upload timestamp, validation status, and a pre-signed download URL with a 15-minute expiry. It communicates no destructive actions, adding value beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that conveys the core purpose and return fields with no extraneous words. Front-loaded with the verb and resource.
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, the description adequately lists return fields. It lacks details on pagination or sorting, but given the tool's simplicity and sibling context, it is nearly complete for agent decision-making.
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 100% and each parameter is described. The description does not add additional meaning beyond what the schema provides for the parameters, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all files uploaded or ingested for an evidence item', specifying the verb and resource. It distinguishes from siblings like scf_get_evidence_file (which retrieves a single file) and scf_list_evidence (which lists evidence items, not files).
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 implies use for listing files associated with an evidence item. It contrasts with scf_get_evidence_file, which is for downloading a specific file. However, it does not explicitly state when to avoid this tool or provide usage exclusions.
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 full burden. It discloses that it is a write operation, requires editor+ role, performs upsert, and only applies provided fields (partial update). It does not mention rate limits or other advanced traits, but sufficiently covers the key behavioral aspects for an update tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 22 words across two sentences. It front-loades the purpose and immediately provides important behavioral details (upsert, role requirement, partial update). Every sentence adds value with no redundancy or 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?
Given the tool has 10 parameters, 2 required, and no output schema, the description adequately covers the essential behaviors (upsert, partial update, tracking fields scope). It could optionally mention the mandatory identifiers (evidence_id, org_id) but those are already in the schema. Overall, it provides sufficient context for an agent to understand the tool's function and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described. The description adds value by clarifying that all body fields are optional and only provided fields are applied, reinforcing partial update semantics. It also groups parameters as 'tracking fields', adding context beyond individual 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 clearly states the verb ('Upsert'), the resource ('evidence item's tracking fields'), and the action ('write — editor+ role'). It distinguishes from sibling tools like scf_create_evidence by specifying 'tracking fields' and 'upsert' behavior, making it unambiguous.
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 implies this tool is used for updating tracking fields on an existing evidence item or creating a tracking row if missing. It provides clear context for use, but does not explicitly state when not to use it or mention alternatives like scf_create_evidence for creating a full evidence item.
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 provided, but the description clearly states it lists all domains with examples. It implies a read-only operation. No side effects mentioned, but none expected. Adequate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. No wasted words. Efficient and clear.
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 parameters, no output schema, and low complexity, the description is sufficient. It specifies what is returned (domains) and gives examples. Missing information like return format is not critical for a list 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 input schema is empty (0 parameters), and schema description coverage is 100%. The description does not need to add parameter-specific semantics. This is the best case for this dimension.
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 'List every compliance domain in the SCF taxonomy' which is a specific verb+resource. It distinguishes from siblings like scf_list_controls and scf_list_frameworks by focusing on domains.
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 name and description make it clear when to use this tool: when you need all compliance domains. There is no explicit alternative mentioned, but no sibling tool serves the same purpose, so guidance is adequate.
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?
Describes the tool as listing organizations and returning specific fields, which accurately reflects its behavior. No annotations provided, but the description adequately informs the agent of its read-only, safe 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?
Two sentences, each earning its place: first states purpose and output, second provides usage guidance. No redundancy or fluff.
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?
Fully covers purpose, output, and usage in context of sibling tools. No gaps despite lack of output schema or annotations.
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?
No parameters in schema, so description doesn't need to add parameter info. Baseline of 4 is appropriate given zero 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?
Description clearly states verb 'List', resource 'organizations', scope 'every organization the caller has access to', and output fields 'org UUID, name, subscription tier, and member count'. Distinguishes from sibling 'scf_get_organization' which retrieves a single org.
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?
Explicitly says 'Use this first to obtain the org_id other tools need', providing clear when-to-use guidance and context for downstream tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-scf MCP server](https://glama.ai/mcp/servers/MarkAC007/mcp-server-scf/badges/card.svg)](https://glama.ai/mcp/servers/MarkAC007/mcp-server-scf)

Score Badge

Copy to your README.md:

[![mcp-server-scf MCP server](https://glama.ai/mcp/servers/MarkAC007/mcp-server-scf/badges/score.svg)](https://glama.ai/mcp/servers/MarkAC007/mcp-server-scf)

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/MarkAC007/mcp-server-scf'

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