audit

create_sulvo_signup_account

Run normal Sulvo signup step 2: create the pending Sulvo user/account. The current signup backend requires a password before the account can continue to ads.txt and review.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`email`	Yes	Applicant email address.
`phone`	No
`domain`	Yes	Primary publisher root domain used in signup start.
`lastName`	Yes
`password`	Yes	Password for the pending Sulvo account. This is required by the current signup backend.
`firstName`	Yes
`utmMedium`	No
`utmSource`	No
`mixpanelId`	No
`utmContent`	No
`outputFormat`	No		markdown
`monthlyPageviews`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It discloses that the tool creates a 'pending' account, implying a temporary state, and notes the password requirement. However, it does not address error conditions (e.g., duplicate email) or side effects, which are important for a creation tool.

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

Conciseness4/5

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

Two sentences are concise and front-loaded with the core purpose. The second sentence ('password required by current backend') is somewhat redundant given the schema, but overall there is no wasted text.

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

Completeness2/5

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

With no output schema, the description should clarify return values or next steps (e.g., what happens after creation). It does not mention the optional parameters or expected outcomes, leaving an agent to guess the response structure. Given 12 parameters and complexity, this is insufficient.

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

Parameters3/5

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

Schema description coverage is only 25% (3 of 12 parameters documented). The description does not add any parameter-specific semantics beyond the schema. For example, 'phone', 'utm*', 'mixpanelId', and 'outputFormat' are left unexplained. At baseline 3 for partial coverage, the description fails to compensate.

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

Purpose5/5

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

Description clearly states the tool runs 'normal Sulvo signup step 2' to create a pending user/account. It specifically identifies the step in the signup flow, distinguishing it from siblings like start_sulvo_signup (step 1) and submit_sulvo_signup_documents.

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

Usage Guidelines4/5

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

The description notes that the backend requires a password before proceeding to ads.txt and review, giving some sequential context. However, it does not explicitly state prerequisites (e.g., must have run start_sulvo_signup first) or provide guidance on 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.

All audit tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.7/5.0

Disambiguation3/5

Many tools are clearly scoped (e.g., `create_sulvo_ad_unit` vs `delete_sulvo_ad_unit`), but there is confusion with tools like `run_publisher_revenue_audit` and `get_publisher_revenue_audit_checklist` which sound like they could overlap. Also, `start_sulvo_signup` and `create_sulvo_signup_account` seem to operate on different stages of signup but could be confused at a glance.

Naming Consistency4/5

The naming convention is generally consistent with a `verb_sulvo_noun` pattern (e.g., `create_sulvo_ad_unit`, `delete_sulvo_ad_unit`). The `get_` and `run_` prefixes are used somewhat inconsistently (e.g., `run_publisher_revenue_audit` vs `get_publisher_revenue_audit_checklist`), and some tool names feel a bit verbose, but overall patterns are recognizable.

Tool Count3/5

With 40 tools, the server covers a massive surface area including signup, activation, reporting, and auditing. While each tool has a specific purpose, the number feels somewhat bloated for a single server, suggesting it could be split into more focused sub-servers (e.g., `sulvo-signup`, `sulvo-reporting`). It is on the high end of 'appropriate'.

Completeness4/5

The tool set appears very complete for the Sulvo ecosystem, covering everything from account creation (`create_sulvo_signup_account`) to auditing (`run_agentic_readiness_audit`) and activation (`submit_sulvo_activation_workspace`). The only minor gap is the lack of a direct way to start signup beyond step 1, but this is documented as an API limitation, not a tool gap.

Resources

Need Help?