Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-sac-tools List all users"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server for SAP Analytics Cloud — enables AI assistants to interact with SAC stories, models, data, users, and audit logs via the SAC REST API.
27 tools across 7 categories: stories, data export, data import, user/team management (SCIM 2.0), audit, resources, and diagnostics.
sac_list_stories / sac_get_story — Browse stories with optional model metadata
sac_list_resources / sac_get_resource — List content resources (stories, models, folders)
sac_list_models — List all models/providers on the tenant
sac_get_model_metadata — Get model schema (dimensions, measures, types)
sac_read_fact_data — Query fact data with OData filtering, paging, column selection
sac_read_master_data — Read dimension member master data
sac_read_audit_data — Read model-level change logs
sac_create_import_job — Allocate a staging area for data import
sac_post_import_data — Push rows to staging (does not touch model yet)
sac_validate_import — Validate staged data before committing
sac_run_import — Execute import (async)
sac_import_status — Check import job progress
sac_import_invalid_rows — Retrieve rejected rows
sac_list_users / sac_get_user / sac_create_user / sac_update_user / sac_delete_user
sac_list_teams / sac_get_team / sac_create_team / sac_update_team / sac_delete_team
sac_export_audit_activities — Export tenant audit/login activities
sac_server_status — MCP server health check
Related MCP server: SAP Datasphere MCP Server
SAP Analytics Cloud tenant with API access enabled
OAuth 2.0 client configured in SAC (Administration → App Integration → OAuth Clients)
Grant type: Client Credentials
Note down: Client ID, Client Secret, Token URL
Node.js v18+
# Install dependencies
npm install
# Copy and fill in your credentials
cp .env.example .env
# Edit .env with your SAC tenant details
# Build
npm run build
# Test with MCP Inspector
npm run inspectVariable | Required | Description |
| Yes | SAC tenant URL (e.g. |
| Yes | OAuth token endpoint (e.g. |
| Yes | OAuth client ID |
| Yes | OAuth client secret |
| No | Cache TTL in seconds (default: 300) |
| No | Log level: info, debug, error (default: info) |
Add to claude_desktop_config.json:
{
"mcpServers": {
"sap-analytics-cloud": {
"command": "node",
"args": ["c:\\path\\to\\mcp-sac-tools\\dist\\index.js"],
"env": {
"SAC_TENANT_URL": "https://mytenant.eu10.sapanalytics.cloud",
"SAC_TOKEN_URL": "https://mytenant.authentication.eu10.hana.ondemand.com/oauth/token",
"SAC_CLIENT_ID": "your-client-id",
"SAC_CLIENT_SECRET": "your-client-secret"
}
}
}
}"Show me all stories" → calls sac_list_stories
"What data is in the Revenue model?" → calls sac_list_models → sac_get_model_metadata → sac_read_fact_data
"List all users" → calls sac_list_users
"Import this sales data into model X" → calls sac_create_import_job → sac_post_import_data → sac_validate_import → sac_run_import
src/
├── index.ts # Entry point (stdio transport)
├── server.ts # Server factory (wires APIs → handlers)
├── auth/
│ ├── oauth.ts # OAuth 2.0 client credentials
│ └── token-manager.ts # Token caching with auto-refresh
├── api/
│ ├── sac-client.ts # Authenticated HTTP client (CSRF handling)
│ ├── stories.ts # /api/v1/stories
│ ├── data-export.ts # /api/v1/dataexport (OData CDI)
│ ├── data-import.ts # /api/v1/dataimport
│ ├── scim.ts # /api/v1/scim2
│ ├── audit.ts # /api/v1/audit
│ └── resources.ts # /api/v1/Resources
├── handlers/
│ ├── BaseHandler.ts # Abstract base (jsonResponse/errorResponse)
│ ├── StoryHandlers.ts
│ ├── DataExportHandlers.ts
│ ├── DataImportHandlers.ts
│ ├── ScimHandlers.ts
│ ├── AuditHandlers.ts
│ ├── ResourceHandlers.ts
│ └── DiagnosticHandlers.ts
├── cache/
│ └── cache-manager.ts # TTL-based in-memory cache
└── types/
└── sac.ts # TypeScript interfacesFork the repository
Create a feature branch (git checkout -b feature/my-feature)
Commit your changes (git commit -am 'Add my feature')
Push to the branch (git push origin feature/my-feature)
Open a Pull Request
ISC — see LICENSE for details.
Create a new data import job for a model. This allocates a staging area. Specify dataType='factData' (default) or 'masterData'. Returns a jobId for subsequent operations.
| Name | Required | Description | Default |
|---|---|---|---|
| modelId | Yes | The model/provider ID | |
| dataType | No | Type of data to import (default: factData) | |
| dimensionName | No | Required when dataType is 'masterData' — the dimension name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it allocates a staging area and returns a jobId, which is helpful. However, it does not disclose potential side effects (e.g., cost, limits), authorization requirements, or the exact nature of the staging area. The behavioral impact is partially transparent but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each providing essential information. Front-loaded with the primary purpose. No redundant or filler content. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no output schema, the description covers the key aspects: creation of a job, allocation of staging area, parameter choices, and output (jobId). However, it could include more details about the staging area's capacity or cleanup to be fully complete for an agent unfamiliar with the system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds significant value by explaining the default value for dataType and the condition for dimensionName (required when dataType='masterData'), which goes beyond the schema and clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates a new data import job for a model and allocates a staging area. The verb 'create' and resource 'import job' are specific. Distinguishes from siblings like sac_post_import_data, sac_validate_import, sac_run_import by being the initial step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on specifying dataType (factData or masterData) and mentions that dimensionName is required for masterData. Implicitly indicates this is the first step in a multi-step import process by noting it returns a jobId for subsequent operations, but does not explicitly state when not to use or list prerequisites like model existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new team in SAC with optional initial members.
| Name | Required | Description | Default |
|---|---|---|---|
| memberIds | No | Array of user IDs to add as members | |
| displayName | Yes | Team name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states 'Create a new team', implying mutation but provides no details on side effects, required permissions, idempotency, or behavior when the team already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is front-loaded with the purpose and includes the optionality detail efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with two parameters and no output schema, the description covers the basics. However, it lacks details on return value, error scenarios, and uniqueness constraints, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters adequately. The description adds the word 'optional' for initial members, which reinforces the schema but does not add significant new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (team), and it notes the optional initial members feature. It is distinct from siblings like sac_create_user, but does not explicitly differentiate from other create tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like sac_update_team or sac_list_teams. No mention of prerequisites, such as required permissions or whether the team name must be unique.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new user in SAC.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Email address | ||
| active | No | Whether the user is active (default: true) | |
| userName | Yes | Unique user name / login | |
| givenName | No | First name | |
| familyName | No | Last name | |
| displayName | No | Display name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as error handling, permissions, or side effects. The description is too minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but at the expense of necessary detail. It is not verbose, but it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description does not provide enough context about return values, constraints, or post-creation behavior. Significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the parameter descriptions already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and identifies the resource 'new user in SAC'. It is clear but does not differentiate from sibling tools like sac_update_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or typical scenarios mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a team from SAC.
| Name | Required | Description | Default |
|---|---|---|---|
| teamId | Yes | The SCIM group/team ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only says 'Delete a team' but fails to mention irreversibility, side effects (e.g., removing associated data), permissions needed, or success/failure responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool, the description omits critical context like irreversibility, return value, and error conditions. For a delete operation, more completeness is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with param description 'The SCIM group/team ID to delete.' The description adds no extra meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (team), distinguishing it from sibling tools like sac_create_team, sac_get_team, and sac_list_teams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, no context about whether to use this over other team operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a user from SAC. This action cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | The SCIM user ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the irreversible nature ('This action cannot be undone'), which is a key behavioral trait, but lacks other context like required permissions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, delivering essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool, the description covers purpose and irreversibility, but lacks details on prerequisites, idempotency, or return values given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add meaning beyond the schema's description of the userId parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'user from SAC', distinguishing it from sibling tools like update or list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as updating or creating a user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mint a fresh OAuth token (bypassing the cache) and report its decoded JWT payload — scopes, authorities, audience, expiry. Use this to verify that an OAuth client scope change has propagated to the issued bearer token. Never returns the raw token; only a 16-char prefix for traceability.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains that the tool bypasses the cache and returns a decoded payload (scopes, etc.), and never returns the raw token. However, potential side effects (e.g., token invalidation) or prerequisites (e.g., authentication) are not mentioned. This is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core action and output. Every word is meaningful; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers the essential behavior: what it does, what it returns (and what it doesn't return), and a typical use case. It could mention error conditions or required permissions, but for a diagnostic tool it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is trivially 100%. The description adds no parameter meaning but doesn't need to. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool mints a fresh OAuth token and reports its decoded JWT payload. The verb 'mint' and resource 'OAuth token' are specific. It distinguishes itself from sibling tools (none of which diagnose tokens).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool to verify OAuth client scope change propagation. It provides a clear use case. It does not explicitly exclude other uses or mention alternatives, but no other tool serves this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export audit/login activities from the SAC tenant. Filter by date range and activity type. Useful for compliance and monitoring.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date (ISO format) | |
| from | No | Start date (ISO format, e.g. '2025-01-01') | |
| pageSize | No | Number of results per page | |
| pageNumber | No | Page number (1-based) | |
| activityType | No | Filter by activity type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It omits behavioral details such as whether the export is non-destructive, pagination behavior despite pageSize/pageNumber parameters, output format, or any side effects. The term 'export' is used without clarification of the result format (e.g., file, stream).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and contains no redundant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description lacks details on output format, pagination behavior, and whether the export is synchronous or asynchronous. It also does not mention required permissions or authentication needs, which is critical for an export tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minor reinforcement by mentioning date range and activity type, but does not elaborate on pagination parameters (pageSize, pageNumber) beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it exports audit/login activities with filtering by date range and activity type. It distinguishes the tool's export action from sibling tools like sac_read_audit_data, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Useful for compliance and monitoring,' implying when to use it. However, it does not provide explicit guidance on when not to use it or mention alternatives like sac_read_audit_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download the result package of a completed Content Network export job. Returns base64-encoded bytes plus size and content type. The package is typically a TGZ archive containing the story definition.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The job ID | |
| downloadUrl | Yes | The downloadUrl reported by sac_export_status when the job COMPLETED. Can be absolute or tenant-relative. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return format (base64-encoded bytes, size, content type) and package type (TGZ archive), but does not mention side effects, permissions, or safety profile (e.g., whether it is read-only or idempotent).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are succinct and informative. First sentence states action and return value; second sentence adds relevant detail about the package format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential aspects: purpose, return format, and precondition (completed job). However, it lacks information about error conditions (e.g., what if job not completed) or whether the download is synchronous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it downloads the result package of a completed Content Network export job. Distinguishes from sibling tools like sac_export_start (initiation) and sac_export_status (status check) by specifying it is for downloading after completion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates it is for use after a job has completed, but does not explicitly exclude alternatives or state when not to use it. The parameter downloadUrl is described in schema as coming from sac_export_status upon completion, providing implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current status of a Content Network export job. Returns status, progress, and (when complete) the downloadUrl.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The job ID returned by sac_export_story_start |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It fails to clarify that this is a read-only operation, whether it requires authentication, or how to interpret the status. Key behavioral traits like idempotency or polling recommendations are missing, which is a significant gap for a status-checking tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and key outputs. Every word serves a function; no redundancy or fluff. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 parameter, no output schema), the description covers the essential purpose and return values. It does not list possible statuses or progress format, but for a status polling tool, the description is adequate. Minor improvement would be to mention that status should be polled until completion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'jobId', with schema description stating it is 'The job ID returned by sac_export_story_start'. The tool description adds no additional context beyond this, so parameter semantics fully rely on 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the current status of a Content Network export job.' It specifies the verb (get), resource (status of export job), and return values (status, progress, downloadUrl). This effectively distinguishes it from sibling tools like sac_export_story_start (starts export) and sac_export_download (downloads completed export).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to check progress after starting an export, but it does not explicitly state when to use it or provide alternatives. The sibling tools (sac_export_story_start, sac_export_download) provide context, but the description itself lacks explicit guidance on sequencing or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a Content Network export job for a story (or other resource type). Returns the jobId. Use sac_export_status to poll until COMPLETED, then sac_export_download to fetch the package.
| Name | Required | Description | Default |
|---|---|---|---|
| storyId | Yes | The story ID (resource ID) to export | |
| resourceType | No | Resource type — default 'story'. Use this for non-story exports. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it starts an export job and returns a jobId, but omits permissions, side effects, rate limits, or error conditions. Minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return value (jobId) and workflow with sibling tools. No output schema needed. Lacks details on error handling or prerequisites, but adequate for a simple start-job tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema already fully describes both parameters. Description adds value by hinting 'Use this for non-story exports' for resourceType, but does not add critical extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it starts a Content Network export job for a story or other resource type, returns jobId. Clearly distinguishes from sibling tools like sac_export_status and sac_export_download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to poll with sac_export_status and then fetch with sac_export_download, providing a clear workflow. Lacks explicit exclusions or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the metadata/schema of a model — dimensions, measures, and data types. Use a model ID from sac_list_models.
| Name | Required | Description | Default |
|---|---|---|---|
| modelId | Yes | The model/provider ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly describes the return content but does not explicitly state it is a read-only operation. The behavioral traits are adequately conveyed for a simple GET-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and output, then provide a usage tip. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value (dimensions, measures, data types) and input source, but lacks specification of output format (e.g., JSON structure). For a tool with no output schema, this is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a basic description for 'modelId', but the description adds meaningful context ('Use a model ID from sac_list_models'), improving parameter understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'metadata/schema of a model', specifying the returned components (dimensions, measures, data types). It distinctly identifies the tool's purpose among siblings, which lack direct model metadata retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by instructing to use a model ID from 'sac_list_models', but does not explicitly distinguish this tool from siblings like 'sac_read_fact_data' or mention when not to use it. The prerequisite is helpful but exclusion criteria are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific content resource by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| resourceId | Yes | The resource ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states what the tool does (get details) without mentioning read-only nature, permissions needed, side effects, or limits. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no redundant words. Every word earns its place: verb, object, and qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, the description is adequate but lacks information about return values, pagination, or error handling. With no output schema, some description of expected response would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'resourceId' parameter described as 'The resource ID'. The description adds no additional meaning beyond the schema; it only reiterates 'by ID'. Baseline 3 is appropriate for full schema coverage with no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific content resource by ID' clearly states the verb (Get), the resource (content resource), and the method (by ID). It distinguishes from sibling tools like sac_list_resources (which lists resources) and other 'get' tools for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description is purely functional 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.
Get details of a specific story by its ID, including associated models.
| Name | Required | Description | Default |
|---|---|---|---|
| storyId | Yes | The story ID | |
| includeModels | No | Include model metadata (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing the full burden on the description. The description only mentions that models are included, but fails to disclose any behavioral traits like authentication requirements, rate limits, idempotency, or side effects. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Could be slightly more structured to list what is included, but it is efficient and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with only two parameters, the description covers the basic purpose. However, lacking output schema and annotations, it does not explain the return format, error handling, or permissions. More detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both parameters. The description adds minimal value beyond the schema (e.g., 'by its ID' and 'including associated models' mirror schema descriptions). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get details) and resource (specific story by ID), and mentions the scope ('including associated models'). However, it does not distinguish between similar siblings like sac_get_story_detail or sac_get_story_content, missing a chance to clarify its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sac_get_story_detail or sac_get_story_content. The description implies usage when models are needed, but does not explicitly state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End-to-end: start an export job for a story, poll until complete, then download the package. Returns the export package as base64 bytes plus job metadata. Defaults to a 60-second wait; raise maxWaitSeconds for large stories.
| Name | Required | Description | Default |
|---|---|---|---|
| storyId | Yes | The story ID to export | |
| maxWaitSeconds | No | Maximum time to wait for the job to complete (default: 60) | |
| pollIntervalMs | No | How often to poll job status in ms (default: 2000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It transparently describes the polling behavior and base64 encoding return. However, it omits potential side effects, authentication requirements, or failure modes, which are relevant for a composite action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single dense sentence that conveys the entire workflow. It is efficient but could be improved with clearer structure (e.g., listing steps). Still, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations, so description must compensate. It explains the sequential process but does not detail what 'job metadata' contains, nor does it specify error handling or limits. Adequate for a composite tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds pragmatic context for maxWaitSeconds ('raise for large stories'), providing value beyond the schema. No extra meaning for storyId or pollIntervalMs, but overall good.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs an end-to-end export of a story (start, poll, download) and returns base64 bytes plus metadata. It distinguishes from sibling tools like sac_export_story_start, sac_export_status, and sac_export_download by being the composite version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions default 60-second wait and advises raising maxWaitSeconds for large stories, but does not explicitly state when to prefer this composite tool over the individual export steps (start, status, download) that are present in siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the structural pages and widgets of a story via the Resources('id')/storyPages OData navigation. Returns the parsed payload when JSON, otherwise the raw body and content type so the caller can decide on next steps. Use this when sac_get_story metadata is not enough — e.g. to inspect widget definitions or page layouts.
| Name | Required | Description | Default |
|---|---|---|---|
| rawBody | No | Include the raw body string in the response even when a parsed JSON object is available (default: false) | |
| storyId | Yes | The story ID (resource ID) | |
| maxRawChars | No | Cap the raw body length when rawBody is true or when the response is non-JSON (default: 20000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description explains the OData endpoint, return behavior (parsed JSON or raw body+content type), and hints at the rawBody/maxRawChars parameters. No explicit statement of being read-only, but it's implied by 'fetch'. Good transparency overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with main purpose. Every word adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains what is returned and how parameters affect output. It mentions the OData navigation and when to use, making it complete for a fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining the return behavior in context of rawBody and maxRawChars parameters, showing how they affect output. This enhances understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches structural pages and widgets of a story via OData navigation. It distinguishes from sibling sac_get_story by specifying when to use this tool for more detail. Verb 'Fetch' is specific and resource is clearly identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this when sac_get_story metadata is not enough' and gives an example (inspect widget definitions or page layouts). This provides clear when-to-use guidance and implies alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the link between a SAC story and its underlying source model/CDS view name. Cross-references embedded model descriptions from the Stories API with the data export provider list to identify the source model name (e.g. CDS view or BW query). Also infers the source system type (S4, BW, SAC_IMPORT) from naming conventions.
| Name | Required | Description | Default |
|---|---|---|---|
| storyId | Yes | The SAC story ID or name to resolve model mappings for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to state whether the tool is read-only, has side effects, requires specific permissions, or has any constraints like rate limits. The process description is procedural but not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the main purpose. Every sentence adds value without redundancy, and there is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no output schema, and no annotations, the description provides a reasonable overview of the tool's function and outcome. It could be improved by describing the return format or typical outputs, but it is generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the only parameter 'storyId' as 'The SAC story ID or name to resolve model mappings for', and the description does not add further details about the parameter (e.g., format, examples, or accepted patterns). Schema coverage is 100%, so baseline is 3; no extra value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'resolve' and the resource 'link between a SAC story and its underlying source model/CDS view name'. It also specifies what is cross-referenced and inferred, making the tool's purpose distinct from siblings like sac_get_story or sac_get_story_detail, which do not cover model mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. It simply explains the function without contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific team including its members.
| Name | Required | Description | Default |
|---|---|---|---|
| teamId | Yes | The SCIM group/team ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly indicates a read operation ('Get details'), but no additional behavioral traits disclosed (e.g., idempotency, side effects). Adequate for a simple read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is complete enough. Could mention source of teamId but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes teamId as 'The SCIM group/team ID'. Description adds no extra meaning for the parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'details of a specific team including its members'. Distinguishes from sibling sac_list_teams by specifying a particular team.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when or when-not to use. Implies use when you need details of a specific team with teamId, but does not mention alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific user by their SCIM user ID.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | The SCIM user ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only states 'Get details' without disclosing read-only nature, permissions, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 12 words, front-loaded with action and resource, no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for simple tool, but lacks description of return values or behavior on missing user, given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes userId; description merely restates it, adding no new parameter insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get details' and resource 'specific user', directly distinguishes from sibling tools like sac_list_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as sac_list_users; lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the invalid/rejected rows from a validated import job.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The job ID | |
| modelId | Yes | The model/provider ID | |
| dataType | No | ||
| dimensionName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly indicates a read operation but provides no details on side effects, permissions, or constraints (e.g., job must be validated). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, directly communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the import workflow context (many sibling import tools), the description is too brief. It lacks information about return format, pagination, relationship to other import steps, and how to interpret results. No output schema available to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (jobId and modelId described, dataType and dimensionName not). The description adds no parameter information beyond the schema, leaving the undocumented parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('invalid/rejected rows from a validated import job'), which distinguishes it from sibling import tools like sac_import_status or sac_validate_import.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., after validation, before running import). The phrase 'from a validated import job' implies a prerequisite but doesn't explicitly state it, nor does it mention any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an import job.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The job ID | |
| modelId | Yes | The model/provider ID | |
| dataType | No | ||
| dimensionName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral details such as whether the tool is for polling, whether it returns status codes, or what the response format is. Minimal disclosure beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one short sentence) but lacks essential information. Conciseness is appropriate for a simple status check, but the description is too terse to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that checks import status, the description should mention expected behavior (e.g., polling, possible statuses) or link to related tools like sac_run_import. Without output schema or annotations, it is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, but the description adds no meaning to parameters. The schema already describes jobId and modelId; the description does not explain optional parameters dataType and dimensionName or their purpose in the context of checking import status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Check the status of an import job', providing a specific verb and resource. However, it does not differentiate from sibling tools like sac_export_status or sac_import_invalid_rows, which are similar status-checking tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it doesn't mention that it should be used after starting an import or polling for completion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available models (providers) in the SAC tenant. Returns model IDs and descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses read-only operation ('List...Returns'), but does not mention auth requirements, rate limits, or potential pagination. Adequate for a simple list with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and object. No wasted words. Perfectly concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description covers the essential purpose and output. Could mention that results might depend on user permissions, but for a straightforward list it is sufficient. No contradictions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so schema coverage is vacuously 100%. With no params to describe, baseline 4 applies. No need for additional parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List', clearly identifies resource as 'models (providers)', and states return values ('model IDs and descriptions'). Distinguishes from siblings like sac_get_model_metadata which is for single model details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as sac_get_model_metadata. Does not mention prerequisites, limitations, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List content resources (stories, models, folders, etc.) in the SAC tenant. Can filter by type or parent folder.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Max results to return | |
| skip | No | Number of results to skip | |
| parentId | No | Filter by parent folder ID | |
| resourceType | No | Filter by type (e.g. 'story', 'model', 'folder') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It omits behavioral details such as pagination behavior (top/skip parameters exist but not explained), auth requirements, rate limits, or read-only nature. The agent lacks critical context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence with no extraneous words. It efficiently conveys the core purpose and filtering options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify the return format or structure, but it does not. Important aspects like pagination limits, default behavior, and error conditions are absent. The description is incomplete for a parameterized listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear parameter descriptions for top, skip, parentId, and resourceType. The description adds minimal value by reiterating filter capabilities already expressed in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists content resources (stories, models, folders) in the SAC tenant, with filtering by type or parent folder. This distinguishes it from sibling tools that list specific resource types (e.g., sac_list_stories, sac_list_models).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when listing resources with optional filters, but does not explicitly state when to prefer this over more specific sibling tools like sac_list_stories or sac_list_models. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all stories in the SAP Analytics Cloud tenant. Optionally include model information used by each story.
| Name | Required | Description | Default |
|---|---|---|---|
| includeModels | No | Include model metadata for each story (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the tool lists stories and optionally includes models, but fails to mention important behaviors like pagination, rate limits, or that it is a read-only operation. The description is insufficient for an agent to understand side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences containing no filler. Every word is necessary: it states the action (list), the resource (all stories), the scope (tenant), and the optional enhancement (model info). This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one boolean parameter and no output schema, the description covers the basic function. However, it lacks details on return format, pagination, or potential errors. Given the number of sibling tools, more context would help the agent distinguish when this tool is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (the boolean parameter 'includeModels' is described in the schema). The tool description does not add any additional meaning beyond the schema's property description. By the baseline rule, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all stories in the SAP Analytics Cloud tenant and optionally includes model information. It uses a specific verb (list) and resource (stories), distinguishing it from sibling tools like sac_get_story which retrieves a single story. However, it does not explicitly differentiate from similar list tools like sac_list_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing all stories, but provides no guidance on when not to use it or alternatives. For instance, it does not mention that sac_get_story_detail might be better for detailed single-story retrieval. Usage context is clear but no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List teams (groups) in the SAC tenant.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| filter | No | SCIM filter expression | |
| startIndex | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose any behavioral traits such as result set limits, performance, or side effects. Minimal single sentence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Exceptionally concise single sentence, but lack of structure and additional details reduces effectiveness. Appropriate length for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters and no output schema, the description provides minimal context. No mention of return format, pagination behavior, or any prerequisites. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes three parameters with only 'filter' having a description ('SCIM filter expression'). Description does not explain any parameter, failing to compensate for low schema coverage (33%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List teams (groups) in the SAC tenant,' with specific verb and resource. Distinguishes from siblings like sac_create_team or sac_get_team.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no mention of filtering, pagination, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List users in the SAC tenant. Supports SCIM filtering (e.g. filter='userName eq "john"').
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results per page | |
| filter | No | SCIM filter expression | |
| startIndex | No | 1-based start index for paging |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The mention of SCIM filtering adds some behavioral context, but the description does not disclose pagination behavior (count, startIndex) or any side effects, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at two sentences, front-loaded with the core purpose and then a key feature (SCIM filtering). Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Core purpose and filtering are clear, but the description omits pagination behavior (count, startIndex) and response details. For a list tool with no output schema, slightly more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description confirms the SCIM filter usage but adds no new meaning beyond what the schema already provides for count and startIndex.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List users' with a specific resource (SAC tenant) and includes SCIM filtering support, distinguishing it from related tools like sac_get_user or sac_create_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs. alternatives (e.g., sac_get_user for single user). The description implies usage for listing with optional filtering but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post rows of data to an import job's staging area. Data does not touch the model until the job is run. Rows should be an array of objects with column names as keys.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | Array of row objects to import | |
| jobId | Yes | The job ID from sac_create_import_job | |
| modelId | Yes | The model/provider ID | |
| dataType | No | Type of data (default: factData) | |
| dimensionName | No | Required for masterData imports |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries burden. It explains data is staged and not immediately applied, but lacks details on idempotency, limits, or side effects beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. Purpose and key behavioral constraint are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should cover return value. It doesn't mention response format, error cases, or size limits, leaving gaps for a staging tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline 3. Description adds value by explaining rows structure as array of objects with column names as keys, going beyond generic schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Post rows of data' and resource 'import job's staging area' are specific. It distinguishes from sibling tools like sac_run_import by stating data does not touch model until job is run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage when staging rows for import, but does not explicitly state when not to use or provide alternatives like sac_validate_import or sac_run_import.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read audit/change log data for a model. Shows who changed what data and when.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Max number of rows to return | |
| skip | No | Number of rows to skip | |
| filter | No | OData $filter expression | |
| modelId | Yes | The model/provider ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Read', which implies safety, but lacks details on permissions, rate limits, or side effects. Minimal transparency for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. It front-loads the verb and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should elaborate on the return structure. It only hints at 'who, what, when' but omits details like pagination, record format, or field names. Incomplete for a tool lacking output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no semantic value beyond the schema; it does not explain pagination parameters (top, skip) or filter syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads audit/change log data for a model, specifying it shows who changed what data and when. This distinguishes it from data-reading siblings like sac_read_fact_data and sac_read_master_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for audit data but does not explicitly state when to use this tool versus alternatives like sac_export_audit_activities. 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.
Read fact data from a model. Supports OData query options: $top, $skip, $filter, $select, $orderby. Returns rows as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Max number of rows to return (default: 100) | |
| skip | No | Number of rows to skip (for paging) | |
| filter | No | OData $filter expression (e.g. "Region eq 'US'") | |
| select | No | Comma-separated list of columns to return | |
| modelId | Yes | The model/provider ID | |
| orderby | No | OData $orderby expression (e.g. "Revenue desc") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It indicates a read operation ('Read') and states the return format ('Returns rows as JSON'), but lacks details on idempotency, permissions required, or potential side effects. The baseline is adequate for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of only two sentences. It front-loads the core purpose ('Read fact data from a model') and immediately follows with supported features and output format, ensuring no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description provides the essential purpose and supported features, but it does not specify the response structure (e.g., JSON array vs. object), error handling, or pagination behavior beyond mentioning $top and $skip. It meets minimum completeness for a straightforward read tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described individually. The description adds value beyond the schema by grouping the OData options and explicitly stating support for $top, $skip, $filter, $select, $orderby, which frames the parameters in a standard OData context. This enhances understanding beyond the individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read fact data from a model', which precisely identifies the verb and resource. It distinguishes this tool from siblings like sac_read_master_data and sac_read_audit_data by specifying 'fact data', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as sac_read_master_data or sac_read_audit_data. It does not mention prerequisites, limitations, or context for choosing this tool, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read master data for a specific dimension from a model. Returns dimension members with attributes.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Max number of rows to return | |
| skip | No | Number of rows to skip | |
| filter | No | OData $filter expression | |
| modelId | Yes | The model/provider ID | |
| dimensionName | Yes | The dimension name (e.g. 'Region', 'Product') |
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 reads data (implies read-only), but does not mention authentication requirements, rate limits, error behavior, or pagination support beyond what parameters imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema. The description only vaguely states the return type without specifying structure, pagination behavior, or error handling. Details like OData filter syntax are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the parameter descriptions; it only states the return type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reads master data for a specific dimension from a model and returns dimension members with attributes. This distinguishes it from siblings like sac_read_fact_data and sac_read_audit_data, which read fact data and audit data respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for reading master data, but does not mention when not to use it or reference siblings like sac_read_fact_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute the import — moves data from staging into the model. Runs asynchronously. Use sac_import_status to check progress.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The job ID | |
| modelId | Yes | The model/provider ID | |
| dataType | No | ||
| dimensionName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the tool runs asynchronously, which is important. However, it does not detail success/failure behavior, side effects, or authentication needs, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the purpose, the second adds async behavior and a follow-up action. Perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an async tool with 4 parameters, no output schema, and no annotations, the description is adequate but incomplete. It could explain return values or error handling, but it does cover the core flow (run, then check status).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 2 of 4 parameters have descriptions). The description does not add any parameter-specific meaning beyond what the schema provides, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Execute the import' and the resource 'moves data from staging into the model'. It distinguishes from sibling tools like sac_create_import_job and sac_import_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the asynchronous nature and explicitly recommends using sac_import_status to check progress, providing clear context for usage. It does not specify when not to use it, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the MCP server status including uptime and connection configuration (no secrets exposed).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral transparency. It explicitly states that no secrets are exposed, which adds safety confidence. However, it does not mention authentication requirements, rate limits, or side effects (likely none). For a simple read-only check, this is sufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'Check'. It contains no redundant information and every word is informative. It is appropriately concise for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides a reasonable overview of functionality: checking server status, uptime, and connection configuration. It does not describe the return format (e.g., JSON keys), but for a health check tool, this omission is minor. Overall, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100% (empty schema). The description adds meaning by specifying what is checked (uptime and connection configuration), which goes beyond the schema. For zero-parameter tools, baseline is 4, and the description adds extra context, so a score of 5 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check the MCP server status including uptime and connection configuration'. It distinguishes itself from sibling tools like sac_update_user, sac_list_teams, etc., which focus on different resources (users, teams, stories). The verb 'Check' and resource 'server status' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or when not to use it. It provides no exclusion criteria or alternatives. However, since it's a health check tool with no parameters, the use case is generally obvious. Score reflects the lack of explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a team — change its name or replace its member list.
| Name | Required | Description | Default |
|---|---|---|---|
| teamId | Yes | The SCIM group/team ID | |
| memberIds | No | Full list of user IDs (replaces existing members) | |
| displayName | No | New team name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that memberIds replaces existing members, which is useful. However, no disclosure of permissions, idempotency, or error handling. No annotations present, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description for a mutation tool. Lacks return value info, error states, or validation behavior. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions. Description mirrors schema without adding deeper meaning. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (update), resource (team), and specific attributes (name, member list). Distinguishes from sibling update/create/delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid. Implies usage for team modifications but lacks context on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing user's attributes.
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| active | No | ||
| userId | Yes | The SCIM user ID | |
| givenName | No | ||
| familyName | No | ||
| displayName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'update' but does not disclose whether it performs a partial or full update, required permissions, or side effects. With no annotations, this is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, which is efficient. However, it is overly minimal, sacrificing useful context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description fails to provide enough context for correct usage, such as update behavior, required fields, or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the schema. Schema coverage is only 17% (only userId has a description), yet the description does not clarify any other parameter. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update), resource (existing user), and scope (attributes). It distinguishes from sibling tools like create, get, and delete, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no prerequisites, and no conditions for use. The agent is left to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate the staged data in an import job. Returns validation result including any rejected rows.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The job ID | |
| modelId | Yes | The model/provider ID | |
| dataType | No | ||
| dimensionName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially discloses behavior: it returns validation results including rejected rows. However, it does not state whether the tool is read-only or has side effects, which is a gap given the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise, and front-loaded with the core purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and return value. It lacks explicit mention that the tool does not modify data (important for a validation tool), but given the straightforward nature, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with jobId and modelId documented but dataType and dimensionName lacking descriptions. The tool description does not add any parameter-level detail beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'validate' and the resource 'staged data in an import job', and specifies the return value includes validation result and rejected rows. It distinguishes from sibling tools like sac_run_import and sac_import_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after staging data, but does not explicitly state when to use it versus alternatives, nor does it provide when-not-to-use guidance or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0sac_create_import_jobsac_create_teamsac_create_usersac_delete_teamsac_delete_usersac_diagnose_tokensac_export_audit_activitiessac_export_downloadsac_export_statussac_export_story_startsac_get_model_metadatasac_get_resourcesac_get_storysac_get_story_contentsac_get_story_detailsac_get_story_model_mappingsac_get_teamsac_get_usersac_import_invalid_rowssac_import_statussac_list_modelssac_list_resourcessac_list_storiessac_list_teamssac_list_userssac_post_import_datasac_read_audit_datasac_read_fact_datasac_read_master_datasac_run_importsac_server_statussac_update_teamsac_update_usersac_validate_importEach tool has a clearly distinct purpose, with descriptive names and descriptions that avoid overlap. For instance, story tools are split into get_story (metadata), get_story_detail (structure), and export tools (export pipeline), while import tools cover the full staging-to-execution workflow.
All tools follow the consistent pattern 'sac_verb_noun' (e.g., sac_list_users, sac_create_team, sac_read_fact_data). Verbs are standard and descriptive, making tool purpose immediately clear.
With 34 tools, the set is comprehensive but slightly above the typical range for a single-purpose server. However, the count is justified by the variety of domains covered (users, teams, stories, models, imports, resources, audits, utilities).
The tool surface covers core CRUD for users and teams, story export and detail inspection, model data access and import pipeline, plus resource listing and diagnostics. Missing are story update/delete and permission management, but the primary data operations are well-covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pmankineni/mcp-sac-tools'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
